When finger movement exceeded the motion threshold before the finger was
recognized as a thumb, it would never be regarded as a thumb by the tap system.
This prohibited tapping until the thumb was lifted.
This is fixed by moving the check for the thumb state up such that it
happens before the motion threshold check.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit af86152370)
This device frequently reports large pressure values during normal usage.
It does not require a tight palm threshold, because it is a desktop device
-- not built into a laptop surface -- so we can avoid false positives by
setting a very high threshold.
https://bugs.freedesktop.org/show_bug.cgi?id=105753
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit a1ca02ec88)
Introduced in 416fa44d80 but there was a logic
error: we claimed to require 3 events from a trackpoint before stopping the
touchpad but the timer was only set when we actually stopped the touchpad. So
if a trackpoint sends a single event every second, we'd disable the touchpad
after 3 seconds for the duration of the timeout, then again 3 seconds later,
etc.
Fix this by always setting the timeout and resetting the event counter if no
activity happened.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit c0fd857def)
This device randomly decides that a touch is now a palm, based on
the moon phase, the user's starsign and possibly what the dog had for
breakfast. Since libinput assumes that a touchpad that labels a touch as palm
has reasons to do so, let's unassume this for this device by disabling that
axis altogether and relying on the touch pressure only.
https://bugzilla.redhat.com/show_bug.cgi?id=1565692
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
(cherry picked from commit 74e20e0ae0)
When the X1 Yoga is in tablet mode, one capacitative touch button (windows
key, sends KEY_LEFTMETA) and two side volume buttons are accessible on the
front. The key event comes through the internal keyboard that we disabled in
tablet mode so it stops working.
Luckily the Yoga physically disables the "main" keyboard when in tablet mode,
so all we have to do is skip our code to disable the keyboard and the keys are
working again.
https://bugs.freedesktop.org/show_bug.cgi?id=103749
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 5feaa5f00c)
On slow finger motion, this device also sends a bunch of events with only
pressure updates, followed by a massive coordinate jump. Enable the quirk so
we skip that jump.
https://bugs.freedesktop.org/show_bug.cgi?id=105022
This patch was initially applied as ab55302ef and reverted as e8cb7e4523.
Turns out the issues are unrelated to this patch, so let's re-apply it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 0dccaa8a42)
The touch size threshold was too high, so occasionally libinput would
think the finger had lifted when it hadn't and events would be ignored.
Similarly, the palm threshold was too low, so occasionally libinput would
think a heavy single finger was a palm and ignored that too.
This fixes both of those issues.
https://bugs.freedesktop.org/show_bug.cgi?id=103572
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d5b4558675)
Measured at 200 sensitivity because that's what systemd sets for us
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit cf445f99dc)
This is an external keyboard+touchpad but not recognised as touchpad by the
kernel so it's in mouse emulation mode. Double-taps are sent with impossibly
close timestamps and filtered out by the debouncing code. Since this isn't a
real button that can wear out anyway, let's just disable debouncing on this
device.
https://bugs.freedesktop.org/show_bug.cgi?id=105974
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 23614f7551)
If a touch is in TOUCH_NONE, there is nothing to see here, please move along.
In the case of bug 105696, we were accessing the speed.exceeded_count of a
touch that was released previously, erroneously detecting a speed-based thumb.
The sequence was:
- touch down in slot 0, speed.exceeded_count is reset to 0
- move touch until exceeded_count is greater than our threshold
- touch up in slot 0
- touch down in slot 1 [1]
- touch down in slot 2 (more than 25mm away)
- we counted the slot 0 speed.exceeded_count, labeling the slot 2 touch as
speed-based thumb
[1] peculiar behavior only observed on this device, usually slots get re-used
at the first opportunity so having an inactive slot followed by higher slots
being used is unusual.
https://bugs.freedesktop.org/show_bug.cgi?id=105696
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 928bad9104)
We currently used 0.5mm on touchpads as hysteresis value. This causes pointer
movement delays, it is likely too high. Reduce it to a kernel-set fuzz value
(if any) and see how we go with that. On many touchpads, the fuzz is 8 which
would be closer to 0.2mm on e.g. a T440.
Note that the does some defuzzing anyway, but the response of that function is
nonlinear, e.g. for a fuzz of 8, the physical deltas map to:
phys 0..3 → delta 0
phys 4..7 → delta 1
phys 8..15 → delta 4, 5, 6, 7
phys 16..N → delta 16..N
In other words, we never see some logical deltas 2 and 3. While this shouldn't
matter given the average touchpad resolution, reducing the hysteresis margin
is likely to provide some better response. We never see values 8-15 either
which could be the cause of some pointer jumps we've been seeing.
see https://bugs.freedesktop.org/show_bug.cgi?id=105303
Devices with a fuzz of 0 have the hysteresis margin reduced to 0.25mm (from
0.5mm).
https://bugs.freedesktop.org/show_bug.cgi?id=105108
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit ea7498ef97)
During libinput initialization a list of existing input devices is
retrieved from udev. This can lead to a situation where libinput can
end up processing un-configured devices because of the race generated
by udev events and libinput startup.
Sequence example:
weston - start
udev - device 1 added
weston - get a list of input devices
weston - process device 1 -- undefined behavior
udev - device 1 added - finalized
The problem was found because of incorrect touchscreen association
when in a dual monitor system the secondary touchscreen was
incorrectly associated with output one since udev didn't finish the
device initialization and WL_OUTPUT was missing.
To avoid this situation we skip un-configured devices during libinput
initialization, relying on udev to send events when devices are
fully configured.
Note: due to the peculiarities of udev_device_get_is_initialized(), the
input device is still processed if the call fails. If there are no udev
rules defined for the device, it will never be reported as initialized,
but this is not a problem, because all input devices handled by libinput
must have some udev properties set, therefore they always have rules.
Signed-off-by: Nandor Han <nandor.han@ge.com>
[Pekka: change log to debug, unref device]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 23d543b711)
Regression introduced by 3979b9e16a, bug 105258.
With that commit, we only ended real touches when we had less than nslots fake
fingers down. i.e. tripletap on a 2 slot touchpad would not end the
first/second touch even if the pressure goes below the threshold. e.g. Lenovo
x270 needs this, see https://bugs.freedesktop.org/attachment.cgi?id=137672, it
dips below the pressure threshold for the first slot and ends the second slot
in the same frame as the third finger is detected. Fun times.
Anyway, this breaks semi-mt touchpads, another fine category of devices,
because some of those can detect hovering fingers at low pressure, see bug
105535. Because semi-mt devices are generally garbage, we treat them as
single-touch devices instead. So whenever two fingers are down, we treat both
as above the pressure threshold, even when they're physicall hovering.
Fix this by making the x270 fix conditional on at least 2 slots.
https://bugs.freedesktop.org/show_bug.cgi?id=105535
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 3f5ff113a8)
We're left-shifting the bits but weren't comparing against the l_r_l mask
itself. So if we get a sequence of [1, 1, 0, 1] we didn't detect a wobble
because 0b1101 != 0b101 (what we're looking for).
Fix this by turning it into a right shift, that way the bits fall off
the mask automatic
al
ly
y
y
y
y
. .
_._v.___
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 5883ac7d98)
Otherwise a hovering touch stays around forever even after the finger has
discontinued. This doesn't matter on slots, but for fake fingers the finger
may suddenly end up being forced down/up as a result of the pressure changes
on the real fingers.
So when in maybe_end_touch, switch them back to NONE immediately - hovering
touches do not need to trigger a TOUCH_END event.
https://bugs.freedesktop.org/show_bug.cgi?id=105258
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d8db6b5927)
This changes the hysteresis region to an ellipse (usually a circle), where
previously it was a rectangle (usually square).
Using an ellipse means the algorithm is no longer more sensitive in some
directions than others. It is now omnidirectional, which solves a few
problems:
* Moving a finger in small circles now creates circles, not squares.
* Moving a finger in a curve no longer snaps the cursor to vertical
or horizontal lines. The cursor now follows a similar curve to the
finger.
https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=105306
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 6936a15558)
This state is used by the pre-processing of the touch states to indicate that
the touch point has ended and is changed to TOUCH_END as soon as that
pre-processing is finished.
Sometimes we have to resurrect a touch point that has physically or logically
ended but needs to be kept around to keep the BTN_TOOL_* fake finger count
happy. Particularly on Synaptics touchpads, where a BTN_TOOL_TRIPLETAP can
cause a touch point to end (i.e. 1 touch down + TRIPLETAP) but that touch
restarts in the next sequence. We had a quirk for this in place already, but
if we end the touch and then re-instate it with tp_begin_touch(), we may lose
some information about thumb/palm/etc. states that touch already had. As a
result, the state machines can get confused and a touch that was previously
ignored as thumb suddenly isn't one anymore and triggers assertions.
The specific sequence in bug 10528 is:
* touch T1 down
* touch T2 down, detected as speed-based thumb, tap state machine ignores
it
* frame F: TRIPLETAP down, touch T2 up
* frame F+1: touch T2 down in next frame, but without the thumb bit
* frame F+n: touch T2 ends, tap state machine gets confused because
that touch should not trigger a release
https://bugs.freedesktop.org/show_bug.cgi?id=105258
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 6ccd8e934f)
If we have more BTN_TOOL_*TAP fingers down than we have slots, ignore any
below-threshold pressure changes on the slots. When a touchpad only detects
two touches, guessing whether the third touch has sufficient pressure is
unreliable. Instead, always assume that all touches have sufficient pressure
when we exceed the slot number.
Exception: if all real fingers are below the pressure threshold, the fake
fingers are ignored too.
Related to https://bugs.freedesktop.org/show_bug.cgi?id=105258
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 3979b9e16a)
Only the appletouch has pressure and thus executed that code path
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 21b83dfd0b)
This test worked because on devices that don't use pressure the touches were
reset when BTN_TOUCH when to 0, triggering the 'ignore fake fingers when no
real fingers are down' behavior. But this is a different code path than the
pressure handling, so let's separate those tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 990da54aa6)
The details are explained in comment in the code. That aside, I shall
mention the check is so light, that it shouldn't influence CPU
performance even a bit, and can blindly be kept always enabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104828
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
(cherry picked from commit 400aadd53a)
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
(cherry picked from commit e8dffbd73a)
Prep work for the wobbling detection patch
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
(cherry picked from commit e43bd4ae3a)
The sd-bus interface we're using wasn't public until 221.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 8353eeb5a8)
Missing '+' in the optstring caused it to evaluate all options. If any
argument was passed to a subcommand, libinput-measure would throw an error and
exit.
https://bugs.freedesktop.org/show_bug.cgi?id=105246
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 59550ed21c)
If a single-touch touchpad drops below the pressure threshold in the same
frame where a fake finger is added, we begin a fake touch here. The subsequent
loop ends this fake touch because real_fingers_down is 0.
This causes the tapping code to have a mismatch of how many fingers are down
because it never sees the touch begin event for that finger.
https://bugs.freedesktop.org/show_bug.cgi?id=105160
(cherry picked from commit 01a633b6eb)
