Split the suite and test case name up so it's easier to select with a
double-click in the terminal. Because usually those tests need to be re-run
individually and making that easier is a good thing.
Previously:
:: Failure: ../test/test-tablet.c:4434:touch_arbitration:wacom-cintiq-13hdt-pen-tablet
Now:
:: Failure: ../test/test-tablet.c:4434: touch_arbitration(wacom-cintiq-13hdt-pen-tablet)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A device may have 1 or 2 slots without setting BTN_TOOL_TRIPLETAP, those
devices will fail those tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have the meson test suites now that we can use to filter which tests to
run, let's use those.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This isn't technically needed since those tests aren't in the valgrind test
suite anymore. But let's have it here anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This header is intended to be included in the project, so let's do that and
have proper runtime detection of the valgrind environment.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tablets in left-handed mode are rotated, so we need to rotate the touchpad
part of them too. This doesn't affect all tablets though, some of them are
symmetrical and the left-handed mode merely changes the button order around
(some of the earlier Bamboos). So we rely on libwacom to tell us which device
must be rotated.
The rotation itself is done on the input coordinate itself as we get it. This
way any software buttons, palm zones, etc. are automatically handled by rest
of the code.
Fixes#274
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unlike virtually everything else, the tablet tool was processed at the time
the event was read rather than when the subsequent EV_SYN came in. This causes
difficulties with tablets that send the wrong BTN_TOOL_PEN events.
Moving the tool change processing to tablet_flush() makes the injection of the
BTN_TOOL_PEN event a lot easier, simply flipping the matching bit does the
job. It also makes it easier to ignore duplicate tool updates like we've seen
in #259.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And fix the cases where the default value isn't filled in correctly
Issue found because of the following ubsan error:
../src/evdev-tablet.c:182:19: runtime error: signed integer overflow: 0 - -214783648 cannot be represented in type 'int'
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A few leaks in the test code were found when running linput-test-suite
with the -fsanitize=address option enabled. Clean up these leaks so that
we can more clearly see real issues.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make sure we check the expected sequence more stringent and change the x/y
coordinates on prox in so the kernel doesn't filter them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The test device sent a serial of 0. That would end up creating a new tool in
libinput which is wrong. Let's hope this was just an error in creating the
test device, if the device really sends that sequence, we're in trouble.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the previous code we'd set both tools simultaneously which isn't allowed.
It only worked because the second tool set was the one we cared about.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't require a quirk update, just enable this by default for all tablets. If
we get a proximity out event at the right time, the quirk is disabled for that
tablet for the rest of its lifetime. And it's virtually impossible to have a
false positive here anyway - you cannot hold the pen still enough to not
trigger events for 50ms.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We expect the kernel to transition properly for us, e.g. BTN_TOOL_PEN goes to
0, BTN_TOOL_ERASER goes to 1. Two cases have surfaced recently where this
doesn't happen and debugging this takes time - so let's warn about it to make
it obvious.
Example 1: https://github.com/linuxwacom/libwacom/issues/70
Example 2: https://gitlab.freedesktop.org/libinput/libinput/issues/259
This is just a warning, nothing more. We should just handle that case
accordingly but that requires more effort.
Fixes#260
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This triggers on Fedora 30, even though skip skip the tools options test when
running under valgrind.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that we're emulating everything correctly, let's mark it as proper touch
device.
Two test cases need to be excluded:
- double-down triggers an assert in the test device because this isn't
possible this way with protocol A devices
- the axisrange warning test can't be triggered, mtdev clips those axes
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device mostly behaved like a normal touch device except for
SYN_MT_REPORT. Switch it to behave like a real protocol A device and adjust
the test accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is so we can tell litest to create the device anyway, useful for when all
we have to do in the custom create is allocate some memory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When running the test-suite, don't install our rules for device groups and
model quirks - they're expected to be present already.
Plus, since we copy them from the meson build dir, we don't have
those files available anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Multitap sequences (more than 2 taps) had a 180ms timer set only on press,
not on release.
New taps within those 180ms could either trigger multitap+drag or another
multitap (for N+1 taps), resetting the timer on press once again.
If no new tap appears within those 180ms, the sequence was considered
complete.
This behavior differed from regular taps: for the very first tap of a
sequence the timer was set both on touch and on release.
The multitap timing caused misdetection of triple-tap-and-drag sequences as
the timer was hit frequently. Some of those were correctly detected, others
as tripletap only.
Changing the timer to be set on press **and** release gives us a more lenient
timeout. 180ms for tap-and-drag and 180ms for the next tap down after
release. This was also the behavior for the xorg synaptics driver.
Note that quadruple-tap-and-drag didn't suffer from this because the timeout
resulted in double-tap + double-tap-and-drag. Which has the same
user-visible effect.
This allows us to run the test suite runner against the installed system
rather than always using the build tree quirks.
The actual option will be removed in a future commit, it is just here for
commit consistency and testing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We want to use this from the tests as well soon, so let's move it to a more
generic location. This also changes the API to be slightly more sensible, a
free() is the same cost (and safer) than passing a static buffer in and hoping
we didn't get the size wrong.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All the bits that test for utility functions to work correctly can be run
separately from the main test suite (which tests devices and libinput in
general). These bits here are the ones that test the code itself and aren't
reliant on anything else.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It's a one-liner, we don't need this as a separate file. Plus, this makes the
test suite runner less dependent on the build directory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If more than 255 tests fail, we're returning an exit code outside of the POSIX
standard. This only takes effect for -j1, where we fork off we only ever have
a failed value of 1 anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When using button scrolling, a hardcoded delay of 200 milliseconds between
button down and scroll events being emitted makes fast scrolling gestures feel
clunky and sometimes fail entirely. This feature comes from
xf86-input-mouse, was copied into xf86-input-evdev and reimplemented in
libinput.
This was, as far as can be determined, to allow right clicks without
triggering scrolling. libinput now also has distance triggers (2bbf4a0117)
and sends button events if no movement has happened for long clicks,
regardless of the delay.
The 200ms delay is thus not really necessary anymore, let's drop it to 38ms
which is just above the 3-event threshold for 8/10/12ms intervals which is
most devices.
Fixes#237
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the loop was reduced to BTN_DIGI only, it guaranteed that the BTN_STYLUS
condition was no longer met.
Found by coverity
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These numbers just happened to add up correctly for the motion history to
produce a zero delta for a diagonal movement. Fix it by adding extra events to
flush out any motion history leftovers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test had a loop around the proximity events, so in theory we could've
sent two proximity-in events and still get a positive test.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
