The touchpad_2fg_scroll_initially_diagonal test would semi-reliably fail under
valgrind but succeed otherwise. Cause was that on some devices, the initial
diagonal movement wasn't diagonal enough and closer to a horizontal movement.
This was fine on normal runs, but under valgrind we'd hit the "active
threshold" time limit and lock to horizontal scrolling, ditching the remaining
events and failing the test.
Fix this by calculating the scroll vector based on the device's width/height
ratio and go "more diagonal" on the initial vector.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device looks similar to a MT device on the kernel side, but it's not a
MT device and it's not quite a tablet either. It uses slots to track up to 4
totems off the same device and the only hint that it's not a MT device is that
it sends ABS_MT_TOOL_TYPE / MT_TOOL_DIAL.
udev thinks it's a touchscreen and a tablet but we currently init those
devices as touchscreen (because all wacom tablet touch devices are udev
tablets+tochscreens). So we need a quirk to hook onto this device.
And we use a completely separate dispatch implementation, because adding the
behavior to the tablet interface requires so many exceptions that it's easier
to just add a separate dispatch interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We've used up all bits, so let's extend the enum. (1 << 31) triggers an
assertion because we check for > LITEST_DEVICELESS. So we can't use that bit
without other changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was a copy-paste error in the form of
while(event) {
...}
} while(event);
Found by coverity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some versions [1] of the Lenovo ThinkPad Compact USB Keyboard with TrackPoint USB
have the pointing stick on an event node that has keys but is not a regular
keyboard. Thus the stick falls through the cracks and gets disabled on tablet
mode switch. Instead of adding more hacks let's do this properly: tag the
pointing stick as external and have the code in place to deal with that.
[1] This may be caused by recent kernel changes
Fixes#291
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
WEXITSTATUS() "should be employed only if WIFEXITED returned true", see
wait(2). If a test failed with an abort, WIFEXITED is false and WEXITSTATUS
is... undefined? and apparently zero, so test case failures would cause a
false postive test result.
This doesn't affect a normal test run because check handles the aborts
correctly, but the valgrind invocation with CK_FORK ended up being handle by
litest. So with the result that any abort during valgrind was a silent success
and if there was a memleak in the same process that exited with a signal, the
memleak would be ignored too.
Fixes#267
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
valgrind struggles with too many parallel jobs, too easy to hit timeouts.
Let's reduce this for the valgrind runs.
Meson doesn't let us pass arguments through depending on the setup, so let's
make this an environment value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Set this in the code rather than the environment variable to make it easier to
run valgrind manually.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Running under valgrind, this test often fails when the machine is under load.
Split it up so the events are all processed in one go, reducing the chance of
getting a timeout while processing a previous event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are tablets out there that *sometimes* send the right event sequence,
but are generally broken. So let's not disable that quirk even if we do get a
right sequence.
Affected devices: Lenovo Flex 5
Fixes#248Fixes#290
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We rely on libwacom to set this, but it doesn't do so by default for uinput
devices. Let's set this here so the parts are correctly detected as tablet
touchpads.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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.
