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>
The default setting makes the "Dell Latitude E5510 TouchPad" too sensitive and
consequently difficult to use.
Note that the the size of the TouchPad is detected to be higher than it is
(the side-bars are half out of the TouchPad), see
https://github.com/systemd/systemd/pull/18493 for the hwdb overrides for this
device.
Signed-off-by: Gablegritule <guillet.gabriel@laposte.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Users that need to create the local-overrides.quirks are sometimes hesitant to
do so because /etc/libinput doesn't exist by default. Let's create it on
install.
Related #568
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>