A device may have 1 or 2 slots without setting BTN_TOOL_TRIPLETAP, those
devices will fail those tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 803a99ac05)
Multitap sequences (more than 2 taps) had a 180ms timer set only on press,
not on release.
New taps within those 180ms could either trigger multitap+drag or another
multitap (for N+1 taps), resetting the timer on press once again.
If no new tap appears within those 180ms, the sequence was considered
complete.
This behavior differed from regular taps: for the very first tap of a
sequence the timer was set both on touch and on release.
The multitap timing caused misdetection of triple-tap-and-drag sequences as
the timer was hit frequently. Some of those were correctly detected, others
as tripletap only.
Changing the timer to be set on press **and** release gives us a more lenient
timeout. 180ms for tap-and-drag and 180ms for the next tap down after
release. This was also the behavior for the xorg synaptics driver.
Note that quadruple-tap-and-drag didn't suffer from this because the timeout
resulted in double-tap + double-tap-and-drag. Which has the same
user-visible effect.
We never want to accidentally trigger this one. Where we trigger them on
purpose, we can swap the log handler out first.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This forces events for every ~10ms now. If we want a slower movement, we need
more steps - just like a real touchpad does it.
Cocinelle spatch files were variants of:
@@
expression A, B, C, D, E, F, G, H, I, J, K;
@@
- litest_touch_move_two_touches(A, B, C, D, E, F, G, H, I)
+ litest_touch_move_two_touches(A, B, C, D, E, F, G, H)
The only test that needed a real fix was touchpad_no_palm_detect_2fg_scroll,
it used 12ms before, now it's using 10ms so on the bcm5974 touchpad the second
finger was a speed-thumb. Increasing the events and thus slowing down the
pointer means it's a normal finger and the test succeeds again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Change a number of tests to use 10ms intervals between finger events and fix
the coordinates up accordingly to avoid pointer jumps. This is in preparation
for a test-suite wide use of 10ms intervals.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A three-finger touch may cause slot N to end, in a frame after the
BTN_TOOL_TRIPLETAP. This causes tp->nfinger_down to be decremented to 2 as the
touch switches to MAYBE_END - which happens to be our num_slots. We exit early
and never restore the touch correctly.
Fix this by checking that the number of fake touches is equal to the slots, if
it is higher then we need to check for recovery.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/99
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Semi-MT devices provide a bounding box of the fingers, and internally we don't
treat them as real MT device. Depending which finger currently provides
ABS_X/Y we may get a large jump when the other finger is released.
Basic sequence is finger 1 down, finger 2 down, finger 1 up.
On the last interaction, the ABS_X/Y which was on finger 1's coordinates now
jumps to finger 2's coordinates. This is interpreted as movement by the
tapping code, resulting in missed two-finger taps.
Ignore these movements on semi-mt devices.
https://bugs.freedesktop.org/show_bug.cgi?id=105043
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>
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>
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>
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>
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>
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
Unlike the already-existing thumb detection, a touch may be labelled palm at
any time, not just during the initial touch down. This requires full
integration into the tap state machine to unwind properly. For most states, a
palm detection simply ignores the finger and reverts to the most recent state.
One exception is the case of two fingers down, one finger up followed by the
remaining finger detected as a palm finger. This triggers a single-finger tap
but with timestamps that may be from the wrong finger. Since we're within a
short tap timeout anyway this should not matter too much.
The special state PALM_UP is only handled in one condition (DEAD). Once a
touch is a palm we basically skip over it from then on. If we end up in the
DEAD state after a button press we still need to handle the palm up events
accordingly to be able to return to IDLE. That transition also requires us to
have an accurate count of the real fingers down (palms don't count) so we need
a separate nfingers_down counter for tapping.
https://bugs.freedesktop.org/show_bug.cgi?id=103210
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
8cf6893 removed it to make search/replace easier, restore it for the tests
where we don't want debouncing to automatically be handled.
Still left in place are the various top software button cases. Because of the
button re-routing through the fallback interface we need those to be
debounced.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is via a simple search & replace. Later auditing is needed to switch
clicks that should not be debounced (e.g. touchpads) back to a non-debounced
version.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Do so on the synaptics serial touchpads at least, they're known to cause
cursor jumps when the third finger is down. Not detecting a tap move means
three-finger taps get more reliable on these touchpads.
This change affects gestures who now effectively have to wait for the tap
timeout to happen. It's a trade-off.
https://bugs.freedesktop.org/show_bug.cgi?id=101435https://bugzilla.redhat.com/show_bug.cgi?id=1455443
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes the tapping times shorter and hopefully more obvious. It also fixes
a bug where repeated tripletap (by tapping with one finger while leaving the
other two down) could cause incorrect timestamps.
https://bugs.freedesktop.org/show_bug.cgi?id=100796
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For multitap, we're one tap behind with the button clicks, i.e. we send the
first full click button on the second tap, etc. Remember the timestamps of the
touches so we can send the events with the right timestamps. This makes
tapping more accurate because the time between taps and various timeouts
matter less for double-click detection.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Without this enabled, we stay in the single/double tap part of the state
machine and a triple tap is just a double tap followed by a single tap.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
They weren't originally prefixed but the various tests were, but now that we
only have one test runner binary anyway, the prefix helps sorting the files
easily within e.g. gcov results.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
