Running tests in parallel virtually guarantees a different device is added in
between. What we're testing here is that the device comes back and the
original ref doesn't send events, so a false test failure would still indicate
a bug anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We can't call system() in the signal handler but we are allowed to fork. Do
that, update the hwdb and immediately exit the child again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The udev hwdb takes about 200ms and we still trigger it on each device. The
udev rules don't actually change after compiling, so simply create them
once and remove them after the test run.
For multiple test binaries this needed to be synchronized (which is hard),
hence the previous merge into a single binary for all tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Call it a libinput-test-suite-runner, in subsequent patches we'll handle doing
parallel tests ourselves instead of relying on automake features.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Easier to clean up than knowing all the destination paths we'll install.
Only affects global udev rules so far.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With parallel builds the valgrind test run would run at the same time as the
normal run, the test suite isn't designed for that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These are the simplest examples on how to use libinput and should be enough to
get any potential user started.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In some cases a device may need a device group assigned by a custom udev rule
or hwdb entry. Don't overwrite that with our generated one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Wherever we use an absolute size in mm on the touchpad, switch to the new
helper functions. In a few cases we only need one coordinate so just leave the
other one as 0 in those cases.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And rename to make the return value more obvious
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
And rename to make it more obvious what the return value means.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
And rename to make it more obvious what the return value will mean.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
All these effectively returned bools anyway, switch the signature over to be
less ambiguous.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
These are internal functions, if we need them to return an error code we can
change that at any time. Meanwhile, if we only ever return 0 anyway we might
as well just make them voids to save on error paths.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
The i2c one came from an Dell XPS13. The ALPS one I can't remember but highly
likely they were on Dells and if not, nothing really changes here anyway
because it's not a clickpad and right now only clickpads have dell-specific
behaviour.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, just makes the unit more explicit
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We simply don't have enough space on those touchpads to have an area carved
out for horizontal scrolling. Given that horizontal scrolling is rarely needed
anyway users of these touchpads will just have to cling to scroll bars or use
two-finger scrolling.
Exception are small clickpads because they already have an area blocked off
for software buttons and those small clickpads generally come from a time when
clickfinger wasn't much of a thing yet.
https://bugs.freedesktop.org/show_bug.cgi?id=96910
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
All Dell touchpas appear to have a visual marker on their touchpads. With a
visible marker our middle button can (and should) be much smaller since we
can rely on users to hit the button precisely.
https://bugs.freedesktop.org/show_bug.cgi?id=96710
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
10s is not enough when running the test suite in parallel as any test may have
to wait longer than that to get access to the udev lock. Especially for
tests with multiple timeouts it was too easy to trigger timeouts.
Up the timeout to 30s, this seems reliable enough now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
litest_add_device and litest_delete_device trigger a udev rule reload. This
messes with some test devices and when we run multiple tests in parallel we
get weird errors like "keyboard $BLAH failed the touchpad sanity test".
Still not 100% reliable to run tests in parallel, but it's vastly improved
now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
If the first device we got didn't have the expected syspath we'd leak the
device and cause the valgrind tests to fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Expose the middle button emulation on software buttons as proper config
option. When enabled, remove the middle button software button area.
https://bugs.freedesktop.org/show_bug.cgi?id=96663
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Middle button emulation may be delayed in turning on, but during that delay we
already need to return the desired state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
To unify this we need to move the tagging process forward so tp_init() can
rely on it for config setup. This means moving it to the touchpad init code.
Other than that no real functional changes, the rules stay the same:
* serial/i2c/etc. are considered internal touchpads
* Bluetooth is always external
* USB is external for Logitech devices
* USB is external for Wacom devices
* USB is internal for Apple touchpads
And if we can't figure it out, we assume it's external and log a message so we
can put a quirk in place.
https://bugs.freedesktop.org/show_bug.cgi?id=96735
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Increase the mm move threshold for 3 and 4 finger gestures to 2 and 3 mm,
respectively. In multi-finger gestures it's common to have minor movement
while all fingers are being put down or before the conscious movement starts.
This can trigger invalid gesture detection (e.g. a pinch instead of a swipe).
Increase the movement threshold to make sure we have sufficient input data.
No changes to 2-finger movements.
https://bugs.freedesktop.org/show_bug.cgi?id=96687
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A natural hand position for a 4-finger swipe will have one finger well below
the other triggering the pinch detection. This is obviously wrong, only do the
finger position analysis when we have 2 fingers.
This is only a partial fix, for 3-4 finger gestures chances are high that the
third/fourth finger come in a different event frame. Before that we likely
detect 2 fingers in a possible pinch position and still trigger the code path.
This issue has to be fixed separately.
https://bugs.freedesktop.org/show_bug.cgi?id=96687
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
