Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
This interface handles the buttons on the physical tablet itself, including
the touch ring and the strip.
A notable difference to other libinput interfaces here is that we do not use
linux/input.h event codes for buttons. Instead, the buttons are merely
numbered sequentially, starting at button 1. This means:
* the API is different, instead of get_button() we have get_button_number() to
drive the point home
* there is no seat button count. pads are inherently different devices and
compositors should treat them as such. The seat button count makes sense
when you want to know how many devices have BTN_LEFT down, but it makes no
sense for buttons where all the semantics are handled by the compositor
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
If some elantech touchpads require a hysteresis, let's use some more generic
tag for those touchpads that require correct handling of pointer wobbles.
https://bugs.freedesktop.org/show_bug.cgi?id=94897
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
When the touchpad is disabled, the top software button on the Lenovo T440
series touchpads currently enlarge by a factor of 1.5 (to 15mm). This is not
enough, a user has to rotate the wrist quite uncomfortable when using
the left mouse button.
When the touchpad itself is off anyway we can extend the size of the top
software buttons to the factor 3, i.e. 30mm.
Signed-off-by: Peter Frühberger <peter.fruehberger@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We already handle the case where we have MB emulation active and a middle
button is pressed because we often don't know if we have a middle button on
the device.
But the other way round makes little sense, when a physical middle button is
down emulation should not engage. Test for this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Rather than checking the physical key's state, set a flag for the button to be
down. This enables us to use non-physical buttons (middle button emulation).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The only difference between evdev_pointer_notify_physical_button() and
evdev_pointer_notify_button() is that the former filters out middle button
emulations where applicable.
Doing so effectively disables using a button for scrolling that is also used
for middle button emulation. This is intentional, it is a niche use-case
(and prone to timer races). OTOH some devices exist that only have two buttons
on the pointing stick and require button scrolling. This use-case is given
preference.
https://bugs.freedesktop.org/show_bug.cgi?id=94856
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
libudev's util_replace_chars() replaces the () with underscores so that match
would work too but let's use ? instead to make it look like a regex.
This now activates the rules for all cyapa touchpads, before they wouldn't
have applied to any device.
https://bugs.freedesktop.org/show_bug.cgi?id=93846#c12
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is especially a problem for the cursor tool which can be legitimately
left on the tablet. It wobbles by a couple of device units, resulting in
continuous axis updates to the caller. Pre-filter any of these events by the
axis' fuzz value so we don't even process them.
For ABS_DISTANCE which doesn't have a fuzz we hard-code a minimum fuzz of 2.
This should eventually land in the kernel though.
https://bugs.freedesktop.org/show_bug.cgi?id=94892
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Supposed to be [-1, 1] but we only generated [0, 1]
Reported-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Carlos Garnacho <carlosg@gnome.org>
Makes it easier to determine if this is a libinput bug or something triggered
by the caller waiting too long to call libinput_dispatch().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make sure that changing the accel profile doesn't affect the default
accel profile.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We just returned the current profile instead of the default one. Fix
that.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The libinput_*_get_time() returns a 32 bit unsigned integer, but in the
tests we compared them to a 64 bit unsigned integer. This means that
when the 32 bit integer overflowed, we'd still compare to a
non-overflowed 64 bit integer, causing the tests to fail.
This commit fixes this by always casting the millisecond 64 bit unsigned
integer to a 32 unsigned integer, triggering the same overflow.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This path is hit when we set up an abs device without setting specific axis
ranges. Usually because we only care that the axis is there, not the values,
see the tests of invalid devices.
0xffff is fine as max for most axes but setting it for ABS_MT_SLOT can cause
allocation errors. Reduce to 100 because we don't care about the range anyway
and 100 is still big enough for basic tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Middle button interaction is most commonly to paste and it is a single-event
interaction (button press). We provided middle button in software button mode
by emulating it with a two-finger press with L+R down at the same time. This
is also what many touchpads are spectacularly bad at, it is very common to
detect the physical button down event before the second finger registers,
resulting in left or right clicks where a middle button should be triggered.
Unless the fingers are resting on the touchpad for at least one scanout, the
success rate for middle button emulation is only at 70% or so.
This patch adds a 25%-width middle button area between the left and the right
software button, everything else stays the same. To avoid immediate breakage,
the middle button emulation remains but may be removed in the future.
The doc is updated to only refer to the middle button area now.
https://bugs.freedesktop.org/show_bug.cgi?id=94755
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Resetting the motion history has the side-effect of swallowing movements, we
don't calculate deltas until we have 4 motion events. During a finger release,
we're likely to get a large pressure change between two events, resetting the
motion history prevents the cursor from jumping on release.
The value of 7 found by trial-and-error, tested on the T440 and T450 hardware.
The absolute value is highly variable but recordings show that the pressure
changes only by 1 or 2 units during normal interaction. Higher pressure
changes are during finger position changes but since those should not cause a
jump anyway, we tend to win there too.
Currently only enabled for negative pressure changes, let's see how we go with
that. This is enabled for all touchpads now, but the value may need
device-specific thresholds in the future.
https://bugs.freedesktop.org/show_bug.cgi?id=94379
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous code would swap the top software buttons depending on the
touchpad's left-handed setting, not the trackpoint setting. Changing both
devices to left-handed resulted in a double-swap, i.e. the trackpoint was
always right-handed.
https://bugs.freedesktop.org/show_bug.cgi?id=94733
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Resetting the motion history has the side-effect of swallowing movements, we
don't calculate deltas until we have 4 motion events. During a finger release,
we're likely to get a large pressure change between two events, resetting the
motion history prevents the cursor from jumping on release.
The value of 7 found by trial-and-error, tested on the T440 and T450 hardware.
The absolute value is highly variable but recordings show that the pressure
changes only by 1 or 2 units during normal interaction. Higher pressure
changes are during finger position changes but since those should not cause a
jump anyway, we tend to win there too.
Currently only enabled for negative pressure changes, let's see how we go with
that.
https://bugs.freedesktop.org/show_bug.cgi?id=94379
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Because our delta calculation factors in previous events on touchpads (to
reduce jitter) we may get a nonzero delta if we have an event that doesn't
actually change x or y.
Drop the t->dirty workaround introduced in a608d9d, an event that virtually
disappears can mess up our state machines.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Left over from an earlier version of the t450 quirk (see a608d9dc2c) and
unused in the merged version.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The touchpad's sensors are too far apart (or the firmware interferes), causing
in a jerky movement visible especially on slow motion. We get a bunch of
normal motion events, then only ABS_MT_PRESSURE updates without x/y updates.
After about one mm of movement x/y updates resume, with the first event
covering the distance between the last motion event. That event is usually
accelerated and thus causes a large jump. Subsequent events are sufficiently
fine-grained again.
This patch counts the number of non-motion events. Once we hit 10 in a row, we
mark the first motion update as non-dirty, effectively discarding the motion
and thus stopping the pointer jumps.
https://bugs.freedesktop.org/show_bug.cgi?id=94379
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The HUION 580 has a "consumer control" event node that has an ABS_VOLUME, keys
and a REL_HWHEEL. It has the same VID/PID as the pen tablet and libwacom
labels it as ID_INPUT_TABLET. This causes a crash later when we try to init
pointer acceleration for a device that doesn't have axes.
https://bugzilla.redhat.com/show_bug.cgi?id=1314955
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Had this in a private bug report recently. Missing hooks for open/close just
segfault with little information to debug. Add an assert, this is definitely a
bug in the caller and we don't need to recover from that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
One test for an actual file (so far we only tested /tmp, the directory) and
one for a kernel dev that returns a udev device and thus gets one step further
in the error handling code.
Plus, I saw test code doing this (opening /dev/uinput) and it crashed (for
other reasons), so we might as well test it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the fingers are vertically apart by more than 20mm we used to assume a
pinch gesture immediately. This is too close together for some users during
two-finger scrolling. Since we should always bias towards scrolling, only
trigger this detection for three fingers, the rest has to go through the
movement detection.
The reason for the pinch detection here was to differentiate from 3fg swipe
gestures (83f3dbd1), hence we're still in spirit of that patch.
https://bugs.freedesktop.org/show_bug.cgi?id=94264
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
