Some trackpoints, notably the one on the Lenovo T460s have a tendency to send
the odd event even when they're not actually used. Trackpoint events trigger
palm detection (see 0210f1fee1) and thus effectively disable the touchpad,
causing the touchpad to appear nonresponsive.
Fix this by requiring at least 3 events from a trackpoint before palm
detection is enabled. For normal use it's hard enough to trigger a single
event anyway so this should not affect the normal use-case.
https://bugzilla.redhat.com/show_bug.cgi?id=1364850
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
That's where this device comes from. The x220 is special because it's too
small to trigger some of the features, eg. palm detection. Make this more
obvious by changing to a less generic name.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We print the sysname, but it's not always obvious when there's an event from
another device within the stream from another device. Prefix it so it's easier
to spot and search for.
See https://bugzilla.redhat.com/show_bug.cgi?id=1364850#c3 for an example of
how such an event can hide.
We only use last_device for comparing pointer values so we don't need a
reference to the device, it doesn't matter if the device itself goes out of
scope.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
INPUT_PROP_BUTTONPAD is not set on this device and RMI4 which should fix this
is a bit too far into the future at this point. Hack around it.
https://bugs.freedesktop.org/show_bug.cgi?id=97147
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
So far we've relied on the wacom kernel module to do touch arbitration for us
but that won't be the case in upcoming kernels. Implement touch arbitration in
userspace by pairing the two devices and suspending the touch device whenever
a tool comes into proximity.
In the future more sophisticated arbitration can be done (e.g. only touches
which are close to the pen) but let's burn that bridge when we have to cross
it.
Note that touch arbitration is "device suspend light", i.e. we leave the
device enabled and the fd is active. Tablet interactions are comparatively
short-lived, so closing the fd and asking logind for a new one every time the
pen changes proximity is suboptimal. Instead, we just keep a boolean around
and discard all events while it is set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Touch sequences are interrupted by TOUCH_FRAME events which makes them
annoying to handle event-by-event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Previously suspending a touch device with at least one touch down would never
release the touch point.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
If the touch is inactive the seat_slot is -1 and we filter the event. The same
happens for devices that send may touch events but aren't touch devices like
any touch-capable mouse. In those cases we sent a bunch of 'empty' touch frame
events. Stop this by checking if we actually flushed the respective event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Rather than testing before if we have an event that matches the need for a
frame simply return the event sent by the flush function. If that event
matches those that need frame events, send the event then.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
No functional changes, this is prep work for being able to release touch
points on the fly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
If a tool starts reporting with serial 0 and later updates to a real serial,
discard that serial and keep reporting as serial 0. We cannot really change
the tool after proximity in as we don't know when callers query for the serial
(well, we could know but any well-written caller will ask for the serial on
the proximity in event, so what's the point).
Thus if we do get a serial in and the matching tool, check if we have a tool
with the serial 0 already. If so, re-use that. This means we lose correct tool
tracking on such tablets but so far these seem to only be on devices where the
use of multiple tools is unlikely.
https://bugs.freedesktop.org/show_bug.cgi?id=97526
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Makes the test suitable for tablets without proximity capabilities.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
The touchpad's says it can do two- and three-finger detection but it never
sends events for it. Disable them so we treat it as pure single-finger
touchpad.
https://bugzilla.redhat.com/show_bug.cgi?id=1351285
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Introduced in b02acd346b, we need to check the angle returned by the parsing
function, not the variable passed in.
Found by Coverity
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We leave the old LIBINPUT_MODEL_TRACKBALL in place until we can rely on
systems to have the new systemd tagging.
https://github.com/systemd/systemd/pull/3872
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We've already been doing this for semi-mt devices and for non-clickpads but
let's do it for clickpads as well. On Synaptics touchpads (PS/2 and RMI4)
we see slot jumps where two slots are active, slot X ends but slot Y continues
with the other slot's positional data. This causes a cursor jump on finger
lift after a two-finger scrolling motion. Simply resetting the motion history fixes it.
The only multi-finger interaction where a user could expect perfect fluid
motion is when using a second finger to touch cone of the software button
areas. Let's see if we have complaints first before we implement something
more complex.
https://bugs.freedesktop.org/show_bug.cgi?id=91695
Signed-off-by:Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Probably a copied typo in the original tests, 5 events with 40ms in between
makes less sense than the now-replacement 20 events every 2ms. The previous
one could trigger the cursor jump detection.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This prevents any tests from being added but not run in the normal setup. But
as soon as filters are manually specified on the list proceed anyway.
Otherwise it's impossible to run specific sets of tests, e.g. things like
running all tests applicable to a specific device with
--filter-device=foo
Now that all tests are in the same binary we are guaranteed that at least some
tests don't apply, so the above was guaranteed to abort.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touch was down (and up again) before the device was switched to edge
scrolling, libinput reported an error message:
litest error: libinput bug: unexpected scroll event 0 in area state
While edge scrolling was disabled, any new touch would be set to the area
state but it was never reset on touch release.
https://bugs.freedesktop.org/show_bug.cgi?id=97425
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The Logitech MX master has different click angles for the two wheels.
https://github.com/systemd/systemd/issues/3947
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The only reason to have more than one finger on a non-clickpad is to tap,
scroll or gesture. In all cases resetting the motion history is a good idea to
avoid jumps moving from 2 to 1 finger.
https://bugs.freedesktop.org/show_bug.cgi?id=97194
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previously hardcoded button map for tapping is 1/2/3 to LRM. But the
middle button is a common feature on the desktop (used for paste, most
prominently) and three-finger tapping is almost impossible to do reliably on
some touchpads (e.g. the T440 has a recognition rate of ~1 in 5).
Left and right buttons have a prominent physical position (either softbuttons
or physical buttons) so make the tap order configurable. Those that require
middle buttons reliably can use the [software] buttons for left/right and
2-finger tap for a middle button.
https://bugs.freedesktop.org/show_bug.cgi?id=96962
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The only places we should typecast from device->dispatch is where we have
external entry points. Everywhere else keep the pointer to the dispatch
interface we already have anyway.
This way we avoid papering over a potential re-use of a function from
non-evdev code, passing in the wrong dispatch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
