GitLab

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

The previously hardcoded button map for tapping is 1/2/3 to LRM. But the
middle button is a common feature on the desktop (used for paste, most
prominently) and three-finger tapping is almost impossible to do reliably on
some touchpads (e.g. the T440 has a recognition rate of ~1 in 5).

Left and right buttons have a prominent physical position (either softbuttons
or physical buttons) so make the tap order configurable. Those that require
middle buttons reliably can use the [software] buttons for left/right and
2-finger tap for a middle button.

https://bugs.freedesktop.org/show_bug.cgi?id=96962Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Easier to link to from bug reports
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

The only places we should typecast from device->dispatch is where we have
external entry points. Everywhere else keep the pointer to the dispatch
interface we already have anyway.

This way we avoid papering over a potential re-use of a function from
non-evdev code, passing in the wrong dispatch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

And a minor rename to make it more obvious
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Have the ungrouped items at the top of the struct for better visibility.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This is only used by the fallback dispatch method, not by any of the others.
Anything dispatch-specific should go into that struct.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Rather than setting a magic device field and returning true/false just return
the dispatch method.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

All the other devices are created in there too, unify that approach.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This timeout is there to switch to scrolling when the fingers rest on the
touchpad unmoving and thus avoids the initial scroll threshold for slow
scrolls.

Since the only other gestures we support are swipe (usually a fast movement)
and pinch-and-rotate (also a fast movement) we can drop the timeout down
significantly and thus make the scroll feel more reactive.

https://bugs.freedesktop.org/show_bug.cgi?id=93504Signed-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>

dwt shouldn't trigger on those keys
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

The newer Wacom Cintiqs have touch devices with a different PID than the pen
device. Use the new libwacom_get_paired_device call where available to pair
the two devices and give them the same device group.

This isn't that important just yet, so no need to force users to update to a
new libwacom version.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>

Likely testing a specific set of tests, possibly in gdb. So don't parallelize.
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>

We only have a single test runner now, so no need to restrict it.
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>

Not needed anymore, we only have one process creating the udev rules.

This reverts commit 030ec053.

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>

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>