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>
touchpad_move_after_touch contains support for up to 5 fingers but was only run
with 2..4 fingers.
touchpad_multitap and several others using the same parameter definition were
long ago tested with 3..7 taps. In 8f92b091 this was reduced to 3..4 for CI
performance, while the commit message indicates 3..5 were intended.
The common theme is that the upper bound of `struct range` is interpreted
as exclusive, while some uses assumed it would be inclusive.
There are relatively recent helper functions range_init_inclusive and
range_init_exclusive (since 817dc423) to avoid this trap. Use them on the
remaining two ranged tests.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1142>
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>
The 5th finger was placed in the same position as the 4th finger which
doesn't have an effect in libinput but it looks wrong.
And the first finger was put down at 40/30 but then moved from 70/30 to
the new position, causing pointer jumps on some touchpads.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1145>
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>
These take a long time and have a reasonable high chance of failure due
to the timing constraints. Let's split them up so they don't hog the
runners for that long and in case they fail, we only need to re-run a
short test.
Before: one test running approx 21 min, now 3 tests running approx 7 +
11 + 4 min.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1065>
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>
This are tests with drag lock enabled, so our timeout needs to be
be the tap and drag timeout (which is higher than the normal tap timeout).
Only worked because they're similar enough that if there's a bit of a
delay, the extra ms push us over the line.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/984>
Starting with kernel v5.0 two new axes are available for high-resolution wheel
scrolling: REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES. Both axes send data in
fractions of 120 where each multiple of 120 amounts to one logical scroll
event. Fractions of 120 indicate a wheel movement less than one detent.
This commit adds a new API for scroll events. Three new event types that encode
the axis source in the event type name and a new API to get a normalized-to-120
value that also used by Windows and the kernel (each multiple of 120 represents
a logical scroll click).
This addresses a main shortcoming with the existing API - it was unreliable to
calculate the click angle based on the axis value+discrete events and thus any
caller using the axis value alone would be left with some ambiguity. With the
v120 API it's now possible to (usually) calculate the click angle, but more
importantly it provides the simplest hw-independent way of scrolling by a
click or a fraction of a click.
A new event type is required, the only way to integrate the v120 value
otherwise was to start sending events with a discrete value of 0. This
would break existing xf86-input-libinput (divide by zero, fixed in 0.28.2) and
weston (general confusion). mutter, kwin are unaffected.
With the new API, the old POINTER_AXIS event are deprecated - callers should use
the new API where available and discard any POINTER_AXIS events.
Notable: REL_WHEEL/REL_HWHEEL are emulated by the kernel but there's no
guarantee that they'll come every accumulated 120 values, e.g. Logitech mice
often send events that don't add up to 120 per detent.
We use the kernel's wheel click emulation instead of doing our own.
libinput guarantees high-resolution events even on pre-5.0 kernels.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Hold gestures are notifications about fingers on the touchpad.
There is no coordinate attached to a hold gesture, merely the number of fingers.
A hold gesture starts when the user places a finger on the touchpad and
ends when all fingers are lifted. It is cancelled when the finger(s) move
past applicable thresholds and trigger some other interaction like pointer
movement or scrolling.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Same as after a tap, just with a short drag between tap and 2/3 finger movement.
Also fixes a finger coord typo in one of the previously added test cases.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
We have two behaviors here:
- tap + 2fg -> scrolling
- tap + 1fg move + 2f down -> dragging
Let's document this. The 3fg case only has one situation, so let's test that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These had no consequences apart from occasional "system is too slow" messages,
because the test suite's shorter tap timeout is just barely long enough
for drag-lock, and/or because litest_assert_button_event waits for an event
anyway.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
This only affects the actual dragging part of the tap-and-drag interaction;
n-finger tap-and-drag is supposed to be performed with a n-finger tap
followed by a 1-finger drag.
Allowing a second finger in the middle of a drag is still necessary for a
finger swap, which users may need in long-distance drags, especially when
drag-lock is disabled.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
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>
The kernel/udev set the pressure resolution to nonzero to indicate the value
is in a known scale (units/g). We use that information to disable the
pressure axis on such devices - real pressure cannot be translated to
contact size.
For the kernel patch see:
https://www.spinics.net/lists/linux-input/msg71237.htmlFixes#569
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This touchpad is a true pressurepad and the pressure axis gives us physical
pressure down. Using it as contact size gives flaky touch detection, so let's
just disable the axis until we do something with that value.
Fixes#562
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This covers the addition of two- and three-finger tap-and-drag,
as well as the fix for multitaps with more than one finger in later taps
and the multifinger enhancement to the tap ending drag-lock.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
This commit duplicates the tap states responsible for tap-and drag (TAPPED
and all DRAGGING* states) to cover two-finger and three-finger taps;
the code for the new states is shared with the existing machinery for
one-finger tap-and-drag.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
Where a touch is labelled as palm on TOUCH_BEGIN (edge palms) we would still
feed the touch through the tap state machine. This would trigger the PALM
transition for each state, usually reducing the touch count.
When the touches were later released, the touch count was out of sync,
resulting in an error message. In the case of #488, the trigger was
a single evdev frame with three fingers down, the third of which was an edge
palm:
- touch 1 transitions from IDLE to TOUCH
- touch 2 transitions from TOUCH to TOUCH_2
- touch 3 (the palm) transitioned from TOUCH_2 back to TOUCH
That third transition is invalid, the palm hasn't been seen by the tap state
machine so it should just be ignored.
Fix this by moving making the tap state processing conditional on a touch
state other than TOUCH_BEGIN.
Fixes#488
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>
In the current implementation, movements > threshold and timeouts usually move
to HOLD state and continue from there. Where a finger is lifted, we go back
up the diagram into the previous finger count's HOLD state.
The side-effect of this is that a tap of a finger can be counted as tap even
after a movement:
- two fingers down, move to scroll, hold down
- third finger down, third finger up
This sequence triggers an erroneous three-finger tap. Once the motion
threshold is hit by any touch, no finger must trigger 2/3 finger tap events
while any touch is down.
The false tap is only triggered where the new finger can execute a tap without
any other finger changing any property. This can be triggered on the
reporter's Dell Precision 5520 but on most other touchpads, a new finger down
will trigger slight movement, pressure or touch size updates and thus the bug
cannot be triggered.
Fixes#382
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We only care about the third-finger data here, the movement of the first two
was just to get out of the base tap states. A timeout will do the same thing
here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
