It's too much effort fighting clang-format for these snippets which
all don't really do much anyway but are important to be read easily.
Let's categorically disable all formatting in the test collections and
move on.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1246>
The two remaining ranged tests (abs_device_no_range, abs_mt_device_no_range)
are better served staying with ranges because parametrized tests need to
explicitly list all members of the range, which for these tests is not only
pretty big, but also contains abs axes reserved for future use. Those axes
have no names yet, making a future-proof conversion pretty much impossible.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1142>
Require the type to be added in the litest_test_params_fetch() so we can
easily detect a mismatch. And add some type-safe getters that are much
easier to use for all the tests that only have a single parameter to
fetch anyway.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1139>
This replaces check. The code is a copy of pwtest which I wrote years
ago for pipewire but adjusted for us here the last few days.
There are a few advantages over check:
- Ability to SKIP tests or mark them as NOT_APPLICABLE, the latter
of which is used for early checks if a device doesn't meet
requirements.
- it captures stdout/stderr separately
- colors!
- YAML output format makes it a lot easier to read the results and
eventually parse them for e.g. "restart failed tests"
Less abstraction: we set up the tests, pass them to the runner and run
them with the given number of forks. This is an improvement over before
where we forked into N test suites which each called check which then
forked again. Since we're now keeping track of those processes
ourselves we can also write tests that are expected to fail with
signals.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1067>
This is the first step in switching away from the check framework.
Our litest macros already do almost exactly the same anyway so most of
this is a simple sed with a few compiler fixes where things mismatch
(nonnull -> notnull) and (_tol -> _epsilon).
This now generates a whole bunch of integer mismatch warnings: check
casts everything to intmax_t whereas we use typeof, so lots of warnings
especially for enums.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1059>
Wraps libinput_dispatch() with a location which will make things a bit
easier to track. Output (in --verbose) is something like:
gestures_swipe_3fg_unaccel_fn():1346 - dispatching
Which makes it easier to associate the various calls to libinput
dispatch with the other output from libinput.
This patch switches all uses of libinput_dispatch() in test cases over
but not the litest functions that may call dispatch too. Remains to be
seen if that is necessary.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1048>
Some touchpads, notably those on the Dell XPS 15 9500, are prone to registering
touchpad clicks when the case is sufficiently flexed. Ignore these by
disregarding any clicks that are registered without touchpad touch.
Signed-off-by: Rob Glossop <robgssp@gmail.com>
When one finger is used to hold, tiny pointer movement deltas can easily
end the gesture.
Add a movement threshold to avoid small movement, before or after the hold
timeout, ending the gesture and make the hold-to-interact user
interaction more reliable.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This assumption dates back roughly a decade when INPUT_PROP_BUTTONPAD was
introduced into the kernel. To my knowledge, devices right now erroneously
advertise INPUT_PROP_BUTTONPAD when they are not a clickpad (but then they
have BTN_RIGHT) or they lack INPUT_PROP_BUTTONPAD (and only have BTN_LEFT).
So let's change our assumption here - if a clickpad has a right button log the
kernel bug and continue with the assumption the device is a touchpad with
physical buttons.
To disable that warning, fix the kernel or add an AttrInputPropDisable quirk
for the device.
Fixes#595
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There is only one touchpad with a physical left button but no right button and
that is the old Apple touchpad, discontinued in 2008. Not a huge number of
those left, I assume.
So let's change our assumptions because these days the vast majority of
touchpads are clickpads - any touchpad that only has a left button is treated
as clickpad, even where the kernel doesn't set the INPUT_PROP_BUTTONPAD.
We do need to check for BTN_LEFT as well though, because Wacom touchpads (i.e.
the touch part of non-integrated Wacom tablets) don't have a left button
either.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't middle click on clickpads with click method clickfinger when more than
3 fingers are used.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The group names are forced by check (they are called suite names there) but
for our test suite they provide very little benefit. Much easier to just
use the filename a test is in as group name.
This removes the pure substring match for --filter-group, it's now fnmatch
only. group names are short enough that the typing isn't an issue and we don't
want to run tests twice (e.g. 'pad' is also in 'touchpad').
This patch caused #574 until it got fixed in d838e3a3a4
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is prep work for future devices that announce a wrong slot count. For the
tests this can be a problem if we rely on the correct slot count to decided
whether to run a test or not.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
copy/paste error that makes coverity unhappy. This is the code to correctly
release all touches and the buttons have already been processed above - no
need to reassign here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allowing gestures when holding a physical click enables tasks like
switching workspaces while dragging an icon, but this should only be
possible with a *thumb* holding down the clickpad, not fingers. This
commit restores the ability to hold down the clickpad with two or three
fingers to right- or middle-drag.
Fixes#339, #340
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of a simple yes/no/maybe for thumbs, have a more extensive state
machine that keeps track of the thumb. Since we only support one thumb anyway,
the tracking moves to the tp_dispatch struct.
Test case changes:
touchpad_clickfinger_3fg_tool_position:
with better thumb detection we can now handle this properly and expect a
right button (2fg) press for the test case
touchpad_thumb_no_doublethumb_with_timeout:
two thumbs are now always two fingers, so let's switch to axis events here
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the fingers are in the position in the current code, that's not a 3fg
click, that's a pinch. Let's use something more realistic.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
