A thumb may not move, but may change pressure so we need to process
accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
That's the most likely area it will be resting in, if it's sitting anywhere
above that it's likely part of an interaction.
A thumb in the lowest 15mm needs to trigger the pressure threshold before it's
labelled a thumb. A thumb in the lowest 8mm is considered a thumb if it
remains there for 300ms. Regardless of the pressure, since we can't reliably
get pressure here. If a thumb moves out of the area, or starts outside of that
area it is never a thumb.
If edge scrolling is enabled, the 8mm threshold is ineffective since we'll
have normal interaction in that zone for horizontal scrolling.
The thumb tests now require all touchpads to be switched to clickfinger, if we
test for thumb detection on the bottom of the pad we won't get expected
motion events due to the software button area.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On touchpads with a higher resolution we also see higher pressure values.
Scale accordingly, but use the T440s as reference and don't go below that
device's threshold. A false positive is worse than a false negative when it
comes to thumb detection.
https://bugs.freedesktop.org/show_bug.cgi?id=91362
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The average human hand has four fingers but only one thumb, i.e. the chance of
a fake finger being close to the top-most touch is higher than to whatever the
first touch was (which may be a thumb at the bottom of the touchpad).
So search for the top-most real touch and copy its position into the fake
touches.
This also fixes another bug with the previous code - the first slot may not be
active but we still used its position for the fake touches. Whether that was
really triggerable is questionable though.
The test is only run for the T440 touchpad - we know it's big enough to
enable thumb detection and that way we don't have to double-check in the how
big the touchpad is, etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The use-case we have thumb detection for is to let a user rest a thumb on the
touchpad before clicking. On a touchpad with physical buttons, the thumb won't
be resting on the touchpad.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Gets a bit cramped if you're trying to rest the thumb on a touchpad that
small.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
obsolete since 8658ff159d. And once we remove
that all we checkf or is Apple models which we set a resolution for in
systemd. So that check is obsolete now too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Thumb detection interfered with gestures a fair bit but it shouldn't. A pinch
gesture with a thumb is a fairly natural move so we shouldn't cancel that.
A swipe gesture with a thumb on the touchpad - well, don't do that. No need
for code here.
Reported-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Now that we have all devices init a fixed resolution we don't need code to
handle custom cases anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous approach of using the axis ranges and approximating parameters
based on the x/y axis range clutters up the code and is generally unreliable.
If we look at Synaptics touchpads, the resolution ranges from 42 to 130 while
the axes stay the same axis range. Other touchpads likely have a similar
variation across the various models.
Let's make this simpler in code: unless we know otherwise, simply assume a
default-sized touchpad.
Anything that deviates from that can be fixed with the new hwdb entries to
provide a more correct setting.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
All touchpad recordings seen so far show that a value above 100 is definitely
a thumb or a palm. Values below are harder to discern, and the same isn't true
for touchpads supporting ABS_PRESSURE instead of ABS_MT_PRESSURE.
The handling of a touch is as outlined in tp_thumb_detect:
* thumbs are ignored for pointer motion
* thumbs cancel gestures
* thumbs are ignored for clickfinger count
* edge scrolling doesn't care either way
* software buttons don't care either way
* tap: only if thumb on begin
The handling of thumbs while tapping is the simplest approach only, more to
come in follow-up patches.
Note that "thumb" is the synonym for "this touch is too big to be a
fingertip". Which means that a light thumb touch will still be counted as a
finger. The side-effect here is that thumbs resting a the bottom edge of the
touchpad will almost certainly not trigger the pressure threshold because
most of the thumb is off the touchpad.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested on three laptops here, Lenovo T61, X220 and an HP EliteBook (?), all
with small touchpads. It's hard to have a hand position where the palm touches
the touchpad while using the trackpoint. So we might as well save us the
effort of monitoring events and enabling/disabling it on demand.
As a side-effect this fixes 1233844, but that's more a coincidence.
https://bugzilla.redhat.com/show_bug.cgi?id=1233844
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The touchpad is disabled for 500ms after a trackpoint event to avoid
erroneous palm touches. This is currently refreshed on every trackpoint event
and thus forces a delay of 500ms when switching between the two.
Instead, reduce the timeout to 300ms but ignore any touches started while the
trackpoint was active (i.e. before the last trackpoint event). A touch started
after the last event is released once the timeout expires.
This is the same logic used for disable-while-typing.
https://bugzilla.redhat.com/show_bug.cgi?id=1233844
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We will use this outside of DWT, so set it unconditionally on touch begin.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional changes, just rearranging where it fits better.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We use width/height often enough that storing it once is better than
calculating it on each event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On a touchpad without resolution, the pinned finger was stuck. The motion
distance scale factor ended up as 0 and the finger never reached the threshold
of 3mm.
int was not the best choice of datatype for a value of 0.007...
Fix the data types for xdist/ydist at the same time, clamping to int may cause
erroneous (un)pinning.
Introduced in 8025b374d5https://bugs.freedesktop.org/show_bug.cgi?id=91070
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Most scroll motions would be labelled a palm.
https://bugs.freedesktop.org/show_bug.cgi?id=90980
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
To quote Bryce Harrington from [1]:
"MIT has released software under several slightly different licenses,
including the old 'X11 License' or 'MIT License'. Some code under this
license was in fact included in X.org's Xserver in the past. However,
X.org now prefers the MIT Expat License as the standard (which,
confusingly, is also referred to as the 'MIT License'). See
http://cgit.freedesktop.org/xorg/xserver/tree/COPYING
When Wayland started, it was Kristian Høgsberg's intent to license it
compatibly with X.org. "I wanted Wayland to be usable (license-wise)
whereever X was usable." But, the text of the older X11 License was
taken for Wayland, rather than X11's current standard. This patch
corrects this by swapping in the intended text."
libinput is a fork of weston and thus inherited the original license intent
and the license boilerplate itself.
See this thread on wayland-devel here for a discussion:
http://lists.freedesktop.org/archives/wayland-devel/2015-May/022301.html
[1] http://lists.freedesktop.org/archives/wayland-devel/2015-June/022552.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
On touchpads with resolutions, use a 5mm motion threshold before we unpin the
finger (allow motion events while a clickpad button is down). This should
remove any erroneous finger movements while clicking, at the cost of having to
move the finger a bit more for a single-finger click-and-drag (use two fingers
already!)
And drop the finger drifting, it was per-event based rather than time-based.
So unless the motion threshold was hit in a single event it was possible to
move the finger around the whole touchpad without ever unpinning it.
Drop the finger drifting altogether, if the touchpad drifts by more than 5mm
we have other issues.
https://bugzilla.redhat.com/show_bug.cgi?id=1230462
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This caused the finger to be unpinned on the first motion event after the
click, effectively disabling this feature.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Some touchpads, e.g. the Cyapa in the Acer c720 have a small axis range
([0, 870], [0, 470]), so the diagonal/magic value yields a hysteresis margin
of 1 device unit. On that device, that's one-tenth of a millimeter, causing
pointer motion just by holding the finger.
For touchpads that provide a physical resolution, set the hysteresis axes to
0.5mm and do away with the magic factor.
https://bugzilla.redhat.com/show_bug.cgi?id=1230441
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Our motion filter takes the last couple of vectors to calculate speed,
provided the direction stays the same and it is within a certain timeout. It
does not take into account lifting the finger, so the velocity on the first
event is off.
Real-world impact is mainly on scrolling. Before commit 289e4675
filter: enforce minimum velocity
the first motion on a scroll was accelerated by a factor of 0 and swallowed.
After 289e4675 the motion was calculated based on the timeout and a fraction
of the expected effect. Now the first scroll motion is based on the real
finger motion since setting the finger down and thus feels a bit more
responsive.
It also makes a couple of test cases using litest_assert_scroll() work again
since the miniumum motion is now as expected.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tagging a device should occur only once during configure. We do not
have devices that can be changed after they are configured, so there is no
point in having the tagging part in a deferred struct.
Plus, the note saying that we tag with only one of EVDEV_TAG was wrong.
Now that we are chosing when we call each evdev_tag_*, we can also get
rid of the device->seat_caps tests.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a relative device is tagged by udev as ID_INPUT_TOUCHPAD we need to
catch this before we try to dereference device->abs.absinfo_x.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The current code labels a touch as palm if it started within the typing
timeouts. To move the pointer even after the timeout expires, a user has to
lift the finger which is quite annoying and different to the old synaptics
driver behaviour (which had a simple on/off toggle on whether to let events
through or not).
Be smarter about this: if a touch starts _after_ the last key press event,
release it for pointer motion once the timeout expires. Touches started before
the last key press remain labelled as palms. This makes it possible to rest
the palm on the touchpad while typing without getting interference but also
provides a more responsive UI when moving from typing to using the touchpad
normally.
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>
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>
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>
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>
Check a couple of easy yes/no definitives that cover most Lenovo laptops,
and avoid false positives on Wacoms.
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>
The keyboard test is a simple one, if we have the first row of alphabetic
keys, we assume it's a full keyboard.
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>
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>
Alt-tab should not trigger the disable-while-typing timeout, likewise with the
F-keys, multimedia keys, the windows and menu key, etc.
https://bugs.freedesktop.org/show_bug.cgi?id=90613
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>
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>
Unlikely, but there's the odd chance of the first touch coming in with the
same X or Y coordinate the kernel already has internally. This would
generate a bogus delta on the second event when the touch coordinate jumps
from 0/y or x/0 to the real coordinates.
For touchpads with distance support this is a real issue since the default
value for a touch distance is > 0.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
