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>
Add a second grey v-shaped (upside down triangle) pointer that moves around
with the unaccelerated deltas. This makes it easier to visualize how the
unaccelerated pointer moves around, the snake helps for some use-cases but not
all of them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The assignment of zero is done to work around false-positives of
coverity about uninitialized variable usage. Getting rid of it inside
the macro will allow in later commit to declare a variable inside
`for-loop` rather than outside of it.
Do it by declaring a new list_first_entry_by_type helper which accepts a
type rather than a variable.
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
This makes it easier to visualize changes in various axes or key states that
should not be there, doubly so for long recordings.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Just like the other python-based tools it's just a basename copy, so let's be
consistent here and have all tools perform that way.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Using poll means more difficult fd management, epoll (together with am
modified version of the libinput_sources) makes this a lot easier by simply
using dispatch.
This means we are no longer reliant on a specific file descriptor order in the
poll array.
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>
If we have no events in any of the recorded devices, state that this is the
case and make Enter simply quit instead of a pointless while loop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When running with --with-libinput, the first event is the DEVICE_ADDED event
for our device. Those events do not have a timestamp.
We have to find the first event in the recording with a timestamp instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The doc mentioned 'AttrTouchPressureRange' quirk but `src/quirks.c` defines
'AttrPressureRange' instead. This led to unknown quirk name errors.
Signed-off-by: yuri1969 <1969yuri1969@gmail.com>
Let's leave this up to the compiler, the usual side-effect of inline (compiler
doesn't complain about an unused static function) doesn't apply here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
They all use the same configure_file() process, so let's do them all in a
loop.
Exceptions are the test-suite man page.
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>
Use yq to extract the package list from the CI configuration, then dump that
into the user docs. This provides the long-requested commands to install all
dependencies without the maintenance effort or risk of going stale.
Note that we are *not* building this in the CI, it's just not needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>