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>
If we get to this point, we've already ruled out invalid arguments and this
shouldn't really fail, so let's reply with UNSUPPORTED instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
edit: Luckily there's no overlap between the users of those two flags so this
didn't trigger any bugs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Slight disadvantage: this breaks Ctrl+C to cancel the test suite. Still
potentially better than injecting random events into your vt.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
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>
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>
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>
