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. This is for RMI4 and PS/2, RMI4 is confirmed in the bug
below, let's assume PS/2 has that issue too.
https://bugs.freedesktop.org/show_bug.cgi?id=105640
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
An aborted test run can sometimes leave udev rules as detritus. Test for that
so we don't get test case failures triggered by those rules.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This guarantees the device rules have a static order between test runs.
Previously and in some cases, the temporary file name could affect the order
of the udev rules - let's not do that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
This is the cause of the random test case failures. Because the rule for this
device would also match on the Surface3 lid switch test device it comes down
to whatever mkstemps() picked as the unique characters. When the Surface3
sorted later, everything worked, otherwise it would fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Especially dot is hard to find for some users, so provide the solution to
their problems right there in the error message.
And because users are likely to just copy/paste, remove the disable-libwacom
option. Save them from themselves...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Common problem: some touch sequence does something to confuse libinput but it
cannot easily be captureed. The result is a long sequence of touche that need
to be picked apart and isolated.
Print an easy-to-search for message in the evdev output that signals that the
device touch state is now neutral (i.e. no finger down). Same can be achieved
by searching for BTN_TOOL_FINGER but that provides false positives for
switching between one and two fingers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Collect libinput events together with the evdev events and print them to the
log. This makes it possible to debug the full behavior of a user's machine
rather than having to replay it with potential different race conditions/side
effects.
Example event output:
- evdev:
- [ 2, 314443, 4, 4, 57] # EV_MSC / MSC_SCAN 57
- [ 2, 314443, 1, 57, 1] # EV_KEY / KEY_SPACE 1
- [ 2, 314443, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +87ms
libinput:
- {time: 2.314443, type: KEYBOARD_KEY, key: 57, state: pressed}
- evdev:
- [ 2, 377203, 4, 4, 57] # EV_MSC / MSC_SCAN 57
- [ 2, 377203, 1, 57, 0] # EV_KEY / KEY_SPACE 0
- [ 2, 377203, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +63ms
libinput:
- {time: 2.377203, type: KEYBOARD_KEY, key: 57, state: released}
Note that the only way to know that events are within the same frame is to
check the timestamp. libinput keeps those intact which means we can tell that
if we just had an evdev frame with timestamp T and get a pointer motion with
timestamp T, that frame caused the motion event.
So far, only key, pointer and touch events are printed. We also
hardcode-enable tapping where available until we have options to enable this
on the commandline just because that's useful to have.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having only one finger move (and the second finger at that) in semi-mt device
is not something we can realistically support. We disable the mt axes and
treat semi-mts as single-touch devices, so we don't actually get those events.
The only reason this test passed is because we release the first touch first
here, causing a ABS_X/Y shift that exceeded the motion threshold.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The stop variable set in the signal handler needs
volatile (and use the defined sig_atomic_t instead
of unsigned int).
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
The kernel fuzz handling is buggy, especially when we want to rely on the fuzz
value for our hysteresis. But since this is a hw property and (at least
sometimes) set by the driver, we can't make this a pure libinput hwdb set
either.
So our workaround is:
* extract the (non-zero) fuzz into a udev property so we don't lose it
* set the fuzz to 0 to disable the in-kernel hysteresis
* overwrite our internal absinfo with the property fuzz
This way we get to use the hw-specified fuzz without having the kernel muck
around with it. We also get to use the EVDEV_ABS_ values in 60-evdev.hwdb to
override a driver-set fuzz.
Two drawbacks:
- we're resetting the kernel fuzz to 0, this affects any other users of the
device node. That's probably a minor impact only.
- we can only save this in a udev property there's a risk of this information
getting lost when playing around with udev rules. That too should be a minor
issue.
https://bugs.freedesktop.org/show_bug.cgi?id=105303
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the fuzz is 0, assume we don't need hysteresis and use the wobble detection
code instead. If the fuzz is non-zero, enable it by default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
The hysteresis-returned point always differs from the current point, even if
the hysteresis kicks in. We need to compare to the hysteresis center.
And the returned point is only the new center if we exceed the margin,
otherwise the center stays as-is.
The touch_fuzz() test only succeeded for this because for the values we were
introducing jitter by, the kernel filtered out all the actual movement so
these paths weren't hit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only the ones we care about in libinput but for those it's handy to know which
ones are set (especially the LIBINPUT_MODEL ones).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This needs to be specified as keyword argument, and meson < 0.41 doesn't allow
for a missing fallback.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We expected the first event after TAPPED to be a finger down. If that finger
has been recognised as palm, the finger state isn't TOUCH_BEGIN so we get an
invalid state in our FSM.
libinput bug: 0: invalid tap event TAP_EVENT_PALM in state TAP_STATE_TAPPED
https://bugs.freedesktop.org/show_bug.cgi?id=105370
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes the dependency chain, otherwise a race condition between building
libinput-record and building the git version header causes random build
failures.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some of wacom's tablets, notably the Bamboo series, have a non-predictable
scheme of mapping the buttons to numeric button numbers in libwacom. Since we
promise sequential button numbers, we need to have those identical to
libwacom, otherwise it's impossible to map the two together.
Most tablets have a predictable mapping, so this does not affect the majority
of devices.
For the old-style bamboos, this swaps the buttons around with the buttons
being ordered vertically top-to-bottom in libwacom.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
That function requires us to know which button we're testing for. Because of
the upcoming libwacom changes, we don't know which button we're about to get,
especially on the bamboos. Use the standard libinput functions to get to the
libinput event instead, we don't care about the button numbers here anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
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>
