This way we can ensure that at least one device is available, and that
it is the device we want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
meson uses MESON_TESTTHREADS to determine the number of parallel test
jobs. Since our main test suite cannot be run in parallel anyway, use
that same variable in litest to determine how many jobs we should fork
off.
In the CI pipeline, we can use FDO_CI_CONCURRENT to pass that down so we
don't end up running a billion jobs on a test runner.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
3d3d9b7f69 got rid of the need for a tmp
argument for list_for_each_safe() but switched the loop to be a
multiline statement. This could potentially cause bugs where the loop is
used inside a block without curly braces, e.g.
if (condition)
list_for_each_safe()
func()
The assignment preceding the actual loop would result in the code
reading as:
if (condition)
pos = ....
list_for_each_safe()
The actual list loop would be unconditional.
Fix this by moving the initial assignment into an expression statement.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was observed when running in device mode with:
`libinput debug-events $EVENT_NODE`
When removing the monitored device, the no "device removed" message was
not shown.
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
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>
When 1 or 2 fingers are used to hold, use a faster timer to make the
"hold to stop kinetic scrolling" user interaction feel more immediate.
Also handle double tap and tap and drag interations to send only one
hold gesture instead of two.
Holding with 3 or 4 fingers remains the same to try to avoid callers
missusing hold gestures to build their own tap implementation.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Add an extra parameter to the common gesture test functions to allow to hold
before performing the gesture.
This parameter will be used by the hold tests allowing to share the code.
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>
Valgrind can be too slow to run some time based tests. In those cases, we
need to disable hold gestures.
Add the required functions to configure hold gestures: enable, disable,
get default state and get current state.
Keep them private as they are intended to be used only from the tests.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Add hold gestures to the public API and the private functions to notify them.
Also add hold gestures to debug-events and debug-gui.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
A pinch is defined as two fingers moving in different directions, and a
scroll as two fingers moving in the same direction.
Often enough when the user is trying to pinch, we may initially see both
fingers moving in the same direction and decide that they want to
scroll.
Add a grace period during which we may transition to a pinch in those
situations.
Test fix: touchpad_trackpoint_buttons_2fg_scroll emits movements that
change the distance between fingers, which triggers this new transition
and makes the test fail; correct this.
Signed-off-by: novenary <streetwalkermc@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>
With a new helper function strv_from_argv we can re-use the device opening
loop for all the use-cases we have.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Without this, each finger movement happens in a different evdev event frame.
Since we average deltas for gestures, this messes with the expected data.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's no test case where we need to do something immediately after the last
event so we might as well do everything in the same loop.
This also fixes a bug where the first movement would usually get swallowed.
Test cases in general put the finger down at x/y, then move them to some other
position. We'd expect the first event in a loop to happen at x+n/y+n, not at
x/y again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Incorrect comment, the purpose of this test was to ensure that an unused slot
doesn't affect how other touches are treated, see commit 928bad9.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Got papered over by bugs in the implementation and didn't trigger the jump
detection or movement detection otherwise.
Related to #578
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
So we don't need to worry about the libgen.h include game.
And we can switch trunkname over to that, making it a bit simpler.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
This was just there to avoid unused variable warnings but the simpler approach
to that is to just not assign a variable in the first place.
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>
Some users reported problems triggering multi-finger tap-and-drag,
with reliability decreasing as the finger count increased.
This is plausible because they may shift towards moving the whole hand
up and down, which obviously takes more time than just a finger.
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>
Using buttons for this test can trigger debounce warnings instead (in
addition?) to the warning we actually check for. Let's use motion events
instead and double the loop while we're at it so we have double the chance of
triggering at least one warning.
Fixes#574 for unknown reasons
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
litest itself requires the libinput user_data to be set to its own context
struct (see close_restricted). A test that needs its own user_data must not
override this struct - if the context is accessed during libinput_dispatch()
we'll get memory corruption.
See #574
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
