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>
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>
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>
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>
Inspired by the syndaemon -K switch and Anton Lindqvist's patch.
https://patchwork.freedesktop.org/patch/102417/
We already ignored modifiers for dwt. Now we also ignore modifier + key
combinations, i.e. hitting Ctrl+s to save does not trigger dwt, the touchpad
remains immediately usable.
However, if dwt is already active and a modifier combination is pressed, dwt
remains active, i.e. while typing, a shift + key does not disable dwt.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Wherever we use an absolute size in mm on the touchpad, switch to the new
helper functions. In a few cases we only need one coordinate so just leave the
other one as 0 in those cases.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And rename to make the return value more obvious
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
And rename to make it more obvious what the return value means.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
All these effectively returned bools anyway, switch the signature over to be
less ambiguous.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
These are internal functions, if we need them to return an error code we can
change that at any time. Meanwhile, if we only ever return 0 anyway we might
as well just make them voids to save on error paths.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Expose the middle button emulation on software buttons as proper config
option. When enabled, remove the middle button software button area.
https://bugs.freedesktop.org/show_bug.cgi?id=96663
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
To unify this we need to move the tagging process forward so tp_init() can
rely on it for config setup. This means moving it to the touchpad init code.
Other than that no real functional changes, the rules stay the same:
* serial/i2c/etc. are considered internal touchpads
* Bluetooth is always external
* USB is external for Logitech devices
* USB is external for Wacom devices
* USB is internal for Apple touchpads
And if we can't figure it out, we assume it's external and log a message so we
can put a quirk in place.
https://bugs.freedesktop.org/show_bug.cgi?id=96735
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The removal of the hysteresis even on precise touchpads has led to
difficulties controlling the cursor in a few instances. Since 27078b2667
we only have the hysteresis on Apple touchpads and the Lenovo *40 series and
later. Even on those do we see some positioning difficulties (bug 94379).
So restore the hysteresis by default again for all touchpads. In the future a
knob could be exposed for precision vs reactivity or something, but for now
the drawback of imprecise positioning does not outweigh the benefits we get
on those few devices.
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>
We will reinstate the hysteresis for all devices making the negative
pressure check unncessary.
This reverts commit ef48c07a96.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We will reinstate the hysteresis for all devices making the negative pressure
check unncessary and thus this commit as well.
This reverts commit 2f5231cc88.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This avoids accidental palm detection during two-finger scrolling if one
finger is inside the edge exclusion zone.
Palm detection is designed to avoid accidental touches while typing. If a
non-palm finger is on the touchpad already the user is unlikely to be typing.
So stop palm detection in this case and process the fingers as normal.
This implementation has a minor bug: if both palm touches start within the
palm exclusion zone within the same frame, neither will be labelled as palm
due to how we check the other touches. Since this is an extremeley niche case
we can live with that.
https://bugs.freedesktop.org/show_bug.cgi?id=95417
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These devices are all over the place anyway, no need to spam the log, just
silently discard the jumps.
https://bugs.freedesktop.org/show_bug.cgi?id=96275
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A large part of the bugs seen right now are related to touchpads jittering too
much. Fixing them one by one is entertaining, but time consuming. Right now
the number of touchpads that require a hysteresis seem to outnumber those that
don't, so switch the approach around: leave the hysteresis in place but
disable it for those touchpads that don't need it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Quite a few bugs are caused by touchpad ranges being out of whack. If we get
input events significantly outside the expected range (5% width/height as
error margin) print a warning to the log.
And add a new doc page to explain what is happening and how to fix it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Was only used for the touchpad hysteresis, we can re-use the wobbly touchpad
tag for this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We haven't seen jumps on Wacom tablets yet and they cause error messages in
most of the tests. litest uses a scaling approach for most events, so a finger
move that moves from 30% to 80% of the touchpad with can easily trigger a jump
on a Wacom tablet due to its physical size.
Rather than having to fix up all tests for the larger size (and potentially
cover some other bugs) simply disable this test for Wacom tablets.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This was introduced for bug 94379 - an X1 Carbon 3rd. Other touchpads have
different pressure change ranges, causing this condition to trigger
randomly and resulting in a jerky pointer motion.
For now, reduce the check to the *50 and *60 series touchpads until we have
data for more touchpads that we can add one-by-one.
https://bugs.freedesktop.org/show_bug.cgi?id=95393
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a touch moves by more than 20mm within a single frame, reset the motion
history, effectively discarding the movement. This is a relatively common bug
and almost always needs a kernel fix, so add an explanatory page to the docs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Logitech does not sell internal touchpads, the closest ones are the TK820 and
the K400 series devices. Neither of which need DWT, the touchpad is next to
the keyboard.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
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>
We previously used the half-way mark of the touchpad's y axis to decide where
to ignore tapping. Move this down to the top edge of the software buttons
instead. Users may tap with a finger in the software button areas, on the rest
of the touchpad it's unlikely that they tap within 5% of the edge.
On touchpads with physical buttons or if clickfinger is enabled, the
no-tapping zone extends to the bottom of the touchpad. This required splitting
the tests into clickfinger, softbuttons and hardbuttons.
https://bugs.freedesktop.org/show_bug.cgi?id=93947
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If dwt is disabled on the commandline, e.g. by setting an xinput property it
may be disabled before the release event comes in. This caused the timer to
refresh indefinitely since the key state mask was still on for that key.
Always updating the key state mask (even when dwt is disabled) fixes that.
If a key is held down while dwt is disabled, this can still cause a indefinite
timer refresh, so in the timer func, check if dwt is enabled before refreshing
the timer.
https://bugs.freedesktop.org/show_bug.cgi?id=94015
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a USB keyboard like the YubiKey is found before the internal keyboard, it
will be paired with the touchpad when it is seen. The internal keyboard is
seen later bug ignored because we already have a keyboard paired with the
touchpad.
This is obviously wrong. For now, give priority to serio keyboards, and
override existing dwt pairings with the new keyboard.
https://bugs.freedesktop.org/show_bug.cgi?id=93983
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a key enables dwt and is held down when the timeout expires, re-issue the
timeout.
There is a corner case where dwt may not work as expected:
1. key down and held down
2. dwt timer expires, dwt is re-issued
3. touch starts
4. key is released
5. dwt timer expires
6. touch now starts moving the pointer
This is an effect of the smart touch detection. A touch starting after the
last key press is released for pointer motion once dwt turns off again. This
is what happens in the above case, the dwt timer expiring is the last virtual
key press. This is a corner case and likely hard to trigger by a real user.
https://bugs.freedesktop.org/show_bug.cgi?id=93984
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Some older touchpad devices jitter a fair bit when a finger is resting on the
touchpad. That's why the hysteresis was introduced in the synaptics driver
back in 2011. However, the default value of the hysteresis in the synaptics
driver ended up being 0, even though the code looks like it's using a fraction
of the touchpad diagonal. When the hysteresis code was ported to libinput it
was eventually set to 0.5mm.
Turns out this is still too high and tiny finger motions are either
nonreactive or quite jumpy, making it hard to select small targets. Drop the
default hysteresis by reducing its margin to 0, but leave it in place for
those devices where we need them (e.g. the cyapa touchpads).
https://bugs.freedesktop.org/show_bug.cgi?id=93503
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Synaptics, Elantech and Alps semi-mt devices all have issues with reporting
correct MT data, even the bounding box which semi-mt devices are supposed to
report is wrong.
Synaptics devices have massive jumps with two fingers down. Elantech devices
may open slots without coordinate data. Alps devices may send 0/0 coordinates
as initial slot position.
All these may be addressable with specific quirks, but the actual benefit is
largely restricted to better palm detection (though even with quirks this is
unlikely to work) and support for pinch gestures (again, lack of coordinates
makes supporting those hard anyway).
Elantech: https://bugs.freedesktop.org/show_bug.cgi?id=93583
Alps: https://bugzilla.redhat.com/show_bug.cgi?id=1295073
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
