Ensure we get a -1 return for non-keyboard devices.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On the Logitech T650 it's quite easy to trigger a click without touching the
surface. For software buttons we discard those clicks because we can't tell
where the finger is to decide on left vs right click.
It takes effort to trigger a click with two fingers without triggering a touch
though, so in clickfinger mode post a click without touches as single-finger
click.
https://bugs.freedesktop.org/show_bug.cgi?id=90150
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Split into button and area, the latter of which is the bitmask of which area
we're in. No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some devices need specific configuration or different defaults.
Push that into udev rules and a hwdb file, that's where detection is the
easiest. The LIBINPUT_MODEL_ prefix is used to determine some type of device
model. Note that this property is a private API and subject to change at
any time without notice.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Unlike all the other 2fg scroll tests the touchpad_edge_scroll_no_2fg test
puts the 2 fingers down quite far apart, this makes the pinch vs scroll
gesture detection code in the gestures branch detect a pinch causing the
test to fail.
This commit brings the finger placement in line with the other 2fg scroll
tests fixing this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Similar to libinput_device_pointer_has_button(), this function returns whether
a given device has a specific keycode.
This enables a caller to determine if the device is really a keyboard (check
for KEY_A-KEY_Z) or just a media key device (check for KEY_PLAY or somesuch),
depending on the context required.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
There is quite a wide spread in the delta events generated by trackpoints,
some generate deltas of 1-2 under normal use, while others generate deltas
from 1-20.
It is desirable to normalize trackpoint deltas just like we are normalizing
mouse deltas to 1000 dpi, so as to give different model laptops aprox.
the same trackpoint cursor speed ootb.
Recent versions of udev + hwdb set a POINTINGSTICK_CONST_ACCEL udev property
which can be used to adjust trackpoints which are too slow / too fast
ootb, this commit implements support for that property.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Just setting one of them on a device doesn't guarantee that libinput takes
that as device type.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The goal of this test is to make sure that the deltas are less than 5, which
is the scroll trigger for movement-based edge scrolling. The litest suite
takes percentages of the device, so use a scale factor to change how far we
move on the tablet. The wacom tablet is 141mm, the movement must be smaller to
provide small-enough deltas.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The single finger requirement dates back to when we couldn't configure the
scroll method. Now we can, so let's run the tests on as many suitable devices
as possible.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Just to make sure it is enabled (it should be anyway).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is sort-of legitimate, so simply disable the axes and continue.
Any real axis we require to have a real range.
https://bugs.freedesktop.org/show_bug.cgi?id=90090
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Once we have a doubletap, enter a loop in the state machine where we can tap
multiple times and either get a multi-click or a multi-click drag-and-drop.
The sequence down/up down/up down/up produces a triple-click. The sequence
down/up down/up down/up down produces a triple-click with a button down for
dragging. Yes, that glorious octuple-tap-and-drag, it is now possible. World
domination has been achieved, thank you for playing.
We don't know when we finish tapping now, so add a timeout to send the last
click event once the finger has been released for the last time. This
guarantees that the timestamp of the last button down is later than the
last release. This avoids the bug fixed in synaptics commit
xf86-input-synaptics-1.8.0-21-g37d34f0 (some application don't handle
doubletap correctly without the timestamps).
This works for double-tap immediately, for multi-tap we need to remember the
timestamp of the first press event and use it for the release event so that
there's a forced gap between the release and the second press.
https://bugs.freedesktop.org/show_bug.cgi?id=89511
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Makes it easier from a caller to check for common things without all the other
boilerplate code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If the touchpad has left/right physical buttons but no middle button, force
middle button emulation - without a config option, it's always on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Devices that have left and right buttons but no middle button get middle
button emulation (without config). Devices that have a middle button too get
a config option but default to off. Most mice have LMR set as buttons,
regardless whether they have a middle button.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is just the required framework, it's not hooked up to anything just yet.
Hooking it up comes as separate commit to better detail why/when a device
supports emulation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Adds the following quartett of functions to enable/disable middle mouse button
emulation on a device:
libinput_device_config_middle_emulation_is_available()
libinput_device_config_middle_emulation_set_enabled()
libinput_device_config_middle_emulation_get_enabled()
libinput_device_config_middle_emulation_get_default_enabled()
This patch only adds the config framework, it is not hooked up to anything
yet.
Note: like other features this is merely the config option, some devices will
provide middle button emulation without exposing it as configuration. i.e. the
return value of libinput_device_config_middle_emulation_is_available() only
tells you whether you can _configure_ middle button emulation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional changes at this point, this merely splits up any physical
buttons (i.e. that represent buttons that exist on that device) vs. other
buttons that are emulated in some way or another.
This is in preparation for the addition of middle button emulation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1209753 lists a touchpad 76mm wide
that suffers from palm touches
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Touches in the exclusion zone are ignored for palm detection and don't move
the cursor. Tapping however triggers before we know whether something is a
palm or not, so we get erroneous button clickst.
If a tap happens in the top half of the touchpad, within the palm exclusion
zones, ignore it for tap purposes. To avoid further complicating the state
machine simply pretend there was a movement > threshold on that finger. This
advances the tap state machine properly that no button events are sent for
this finger.
https://bugs.freedesktop.org/show_bug.cgi?id=89625
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Internal touchpads with trackpoints are either BUS_I8042 or BUS_I2C, but not
BUS_USB. Lenovo sells external keyboards with a trackpoint built-in, make sure
we don't pair that trackpoint with the internal touchpad.
And likewise, the internal trackpoint should not be paired with e.g. a wacom
touch device.
Lenovo had one external device that has a trackpoint and a touchpad on an
external keyboard. That device won't be covered with this patch, if we have a
user we can re-consider.
https://bugs.freedesktop.org/show_bug.cgi?id=89935
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
xinput or an equivalent isn't available under wayland, but the majority of
use-cases of "why doesn't my device work" or "why does feature X not work"
should be covered by simply listing the local devices and their config
options.
Example output:
Device: SynPS/2 Synaptics TouchPad
Kernel: /dev/input/event4
Group: 9
Seat: seat0, default
Size: 97.33x62.40mm
Capabilities: pointer
Tap-to-click: disabled
Left-handed: disabled
Nat.scrolling: disabled
Calibration: n/a
Scroll methods: *two-finger
Click methods: *button-areas clickfinger
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This currently requires a specific udev rule to tag the device, once the
matching bits are upstream we can drop this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Follow-up to e2f61b8fb7.
Scroll events are sent through the pointer interface, so we must set the
capability. Otherwise a caller may not have the required bits set up and is a
bit surprised by events coming out of an interface the device doesn't actually
have (xf86-input-libinput crashes when this happens).
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Prints the various pointer accel behaviors into a format understood by
gnuplot, which then provides prettiness.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The main purpose of this patch is to allow the user to actually slow
down pointer movement using libinput_device_config_accel_set_speed, this
is achieved by changing the max-accel setting from "2.0 - speed" to
"2.0 - speed * 1.5", resulting in a max-accel of 0.5 when the user configures
speed at -1.0, the other accel profile parameters are adjusted by the same
factor to keep the curve the same.
This means that the user can get the exact same behavior as before by
multiplying the old setting by 0.6667 (2/3), this also means that this
change not only allows the user to select a slower speed, but to keep
things balanced the same as before, also a higher speed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Less ambiguous since real_touches can be interpreted to "current number of
real touches as opposed to fake touches". Which it isn't, this variable holds
the number of slots.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
