If a tool starts reporting with serial 0 and later updates to a real serial,
discard that serial and keep reporting as serial 0. We cannot really change
the tool after proximity in as we don't know when callers query for the serial
(well, we could know but any well-written caller will ask for the serial on
the proximity in event, so what's the point).
Thus if we do get a serial in and the matching tool, check if we have a tool
with the serial 0 already. If so, re-use that. This means we lose correct tool
tracking on such tablets but so far these seem to only be on devices where the
use of multiple tools is unlikely.
https://bugs.freedesktop.org/show_bug.cgi?id=97526
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Makes the test suitable for tablets without proximity capabilities.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
We've already been doing this for semi-mt devices and for non-clickpads but
let's do it for clickpads as well. On Synaptics touchpads (PS/2 and RMI4)
we see slot jumps where two slots are active, slot X ends but slot Y continues
with the other slot's positional data. This causes a cursor jump on finger
lift after a two-finger scrolling motion. Simply resetting the motion history fixes it.
The only multi-finger interaction where a user could expect perfect fluid
motion is when using a second finger to touch cone of the software button
areas. Let's see if we have complaints first before we implement something
more complex.
https://bugs.freedesktop.org/show_bug.cgi?id=91695
Signed-off-by:Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Probably a copied typo in the original tests, 5 events with 40ms in between
makes less sense than the now-replacement 20 events every 2ms. The previous
one could trigger the cursor jump detection.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This prevents any tests from being added but not run in the normal setup. But
as soon as filters are manually specified on the list proceed anyway.
Otherwise it's impossible to run specific sets of tests, e.g. things like
running all tests applicable to a specific device with
--filter-device=foo
Now that all tests are in the same binary we are guaranteed that at least some
tests don't apply, so the above was guaranteed to abort.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touch was down (and up again) before the device was switched to edge
scrolling, libinput reported an error message:
litest error: libinput bug: unexpected scroll event 0 in area state
While edge scrolling was disabled, any new touch would be set to the area
state but it was never reset on touch release.
https://bugs.freedesktop.org/show_bug.cgi?id=97425
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The Logitech MX master has different click angles for the two wheels.
https://github.com/systemd/systemd/issues/3947
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Inspired by the syndaemon -K switch and Anton Lindqvist's patch.
https://patchwork.freedesktop.org/patch/102417/
We already ignored modifiers for dwt. Now we also ignore modifier + key
combinations, i.e. hitting Ctrl+s to save does not trigger dwt, the touchpad
remains immediately usable.
However, if dwt is already active and a modifier combination is pressed, dwt
remains active, i.e. while typing, a shift + key does not disable dwt.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Don't fork by default if we're in gdb.
Note that is_debugger_attached() is now inside #ifndef LITEST_NO_MAIN, gdb for
the litest selftest will now require a manual CK_FORK=no.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're grouping by test suites, so split up the suites a bit further. The tap
tests all have timeouts and thus take forever, splitting them across multiple
forks means we can finish the test suite quicker.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a make-like -j/--jobs option to split the number of parallel test
processes. Defaults to 8 if not specified, future patches will default this to
1 for special cases where filters are specified or gdb is detected.
Each subprocess overwrites argv[0] to be easier identifiable in the ps
output when we're trying to figure out which tests are still running.
A -j1 is equivalent to the previous functionality, i.e. we don't fork.
One quirk needed for check: any test case not part of a test runner will not
be freed and thus triggers valgrind. We do test filtering by splitting
up the tests across multiple forks (i.e. each process has several tests that
are in the list but not added to the runner). Thus we need to mark those we
expect check to free as used.
Then on cleanup we traverse the test list, add all the unused one to a
test runner and free that test runner (without actually running it). This
cleans up both the filtered tests in each subprocess and the whole test list
in the parent process which doesn't run a test itself.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
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>
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>
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>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Move mode control to libinput. This reduces some flexibility on what we can do
with modes but makes it a lot easier for anyone to implement modes correctly
and have the LEDs apply appropriately, etc. Let's go with the option to make
the 95% use-case easy. Note: whether the mode is actually used is up to the
caller, e.g. under Windows and OS X the mode only applies to the
rings/strips, not the buttons.
A tablet pad has 1 or more mode groups, all buttons/ring/strips are assigned
to a mode group. That group has a numeric mode index and is hooked to the
LEDs. libinput will switch the LEDs accordingly.
The mode group is a separate object. This allows for better APIs when it comes
to:
* checking whether a button/ring/strip is part of a mode group
* checking whether a button will trigger a mode transition
and in the future potentially:
* checking which mode transition will happen
* setting which button should change the mode transition
* changing what type of mode transition should happen.
* moving a button from one mode group to the other
This patch adds the basic scaffolding, without any real implementation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Proofread-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
The removal of the hysteresis even on precise touchpads has led to
difficulties controlling the cursor in a few instances. Since 27078b2667
we only have the hysteresis on Apple touchpads and the Lenovo *40 series and
later. Even on those do we see some positioning difficulties (bug 94379).
So restore the hysteresis by default again for all touchpads. In the future a
knob could be exposed for precision vs reactivity or something, but for now
the drawback of imprecise positioning does not outweigh the benefits we get
on those few devices.
https://bugs.freedesktop.org/show_bug.cgi?id=94379
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
