Probably covered elsewhere in a more generic test anyway but let's have one we
know is executed for all touchpads.
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>
The software button area is currently a partially-dead area. If the finger
moves into or out of the area pointer motion works. Finger motion within the
area however does not generate motion.
The main motivation for this was to avoid accidental pointer motion when a
button is pressed. This is required for stationary fingers but once you move a
significant distance, those bets are off.
So if the finger moves by more than 5mm from where it was put down, release it
and let it move the pointer.
The full impact is largely limited to horizontal movements within the button
area because:
- leaving the finger at the bottom area for 300ms without movement triggers
the thumb identification, so it won't move anyway.
- moving the finger north is likely to go off the button area before we
trigger this threshold.
https://gitlab.freedesktop.org/libinput/libinput/issues/86
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>
We used to completely ignore a finger that was within the top software button
area and then moved to the main area and remained there for a timeout. This
avoids erroneous pointer movements when the user moves the finger while using
the trackpoint.
But we also ignored physical clicks, something we should not be doing. This
patch fixes that behavior: we still ignore the finger for movement, but a
physical click now triggers a left click once we've been in the area for the
timeout.
This new behavior doesn't apply within the timeout, i.e. if a finger is in the
right top button area, moves out and immediately clicks, we still trigger a
right click. This avoids erroneous switches to left-clicks when the finger is
at the edge of the button area and moves out during the press.
Related to: https://bugs.freedesktop.org/show_bug.cgi?id=99212
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touch started hovering in the main area, the button state would start
with AREA and never move to the real button state, despite the finger
triggering the pressure thresholds correctly in one of the areas.
This could even happen across touch sequences if a touch went below pressure
in the software button area, it changed to hovering and the button state
changed to NONE. On the next event, the touch is still hovering and the
current position of the touch is taken for the button state machine.
https://bugs.freedesktop.org/show_bug.cgi?id=99976
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We don't initialize click methods on devices with physical buttons. This model
is a special case, it's not a clickpad but it only has one button (because one
button is all you ever need and whatnot).
https://bugs.freedesktop.org/show_bug.cgi?id=99283
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>
