Put some basic location checks in, if the fingers are next to each other and
vertically close, assume scroll over swipe.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>:
When a touchpad has thumb detection enabled, avoid false-positive gestures
involving a resting thumb by using two thresholds: inner and outer.
While both touches remain inside their inner thresholds, remain in UNKNOWN
state to allow for accurate gesture detection even with no timeout.
If both touches move outside their inner thresholds, start a pinch or
swipe/scroll gesture according to direction, as usual.
If one touch moves outside its outer threshold while the other has not yet
exceeded its inner threshold, and thumb detection is enabled, then if one
touch is >20mm lower, mark it as a thumb and cancel the gesture.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We can't run this in parallel so it doesn't gain us any speed advantage. If
anything, it'll be slower because it's more setup time in between. But: meson
doesn't display the result until the test suite finished, so having this
broken up into smaller chunks means we're more likely to see a general failure
early.
And the failure should be quicker to reproduce as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All filter arguments currently force a -j1 unless otherwise specified. Change
this for --filter-group since that one is most likely invoked by some test
setup that can either add -j X or set the environment variable LITEST_JOBS as
well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Alleged division by zero and use of an uninitialized variable. Both cannot
happen the way we call the tests, so let's just abort to make coverity happy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The coverity compiler can't handle 64-bit enums and since it does provide
useful data, let's switch this to #defines instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Our udev callout is supposed to reset the kernel fuzz to 0 and move the value
to the LIBINPUT_FUZZ property. This is to stop the kernel from applying its
own hysteresis-like approach.
Where the kernel fuzz is nonzero, something has gone wrong with that approach.
Complain about it and set our fuzz to zero, we are in the hands of the kernel
now. If we leave our fuzz as nonzero, we'll apply our own hysteresis on top of
the kernel's and that leads to unresponsive behavior.
Fixes#313
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous movement was one finger still, the second finger moving. This may
cause axis events to trigger when a 2fg scroll gesture was detected. Those
axis events will stop after the gesture timeout but generate one more axis
stop event.
Make two changes here: first, move the fingers like a proper 2fg scroll
motion. And shuffle around the litest_drain_events() calls to ignore any axis
event immediately after the timeout.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test worked because no gesture was detected in the initial movement.
If that happens though, releasing one finger triggers the gesture timeout
during which we suppress events, thus failing the test. Fix this by moving,
waiting, moving - that will definitely generate an event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Second finger's x coordinate was wrong. That we didn't pick this up as pinch
is quite telling too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we're testing for this, let's not try to get it picked up as pinch
gestures. Only an issue on the wacom and magic trackpads because of their
physical size.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We only care about the third-finger data here, the movement of the first two
was just to get out of the base tap states. A timeout will do the same thing
here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I don't think there was a specific reason for the second touch point to jump
around here either and the comment indicates it was just to avoid the
clickfinger distance trigger. So let's just move the first touchpoint.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the fingers are in the position in the current code, that's not a 3fg
click, that's a pinch. Let's use something more realistic.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test was putting both fingers down in the thumb area. That's not
representative, it's more likely that a thumb is in the area and the second
finger clicks elsewhere. So let's test for that instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These were supposed to test the thumb area, but the pressure exceeded the
threshold for most devices, thus ending up testing the palm detection instead.
Fix to use a timeout where possible, otherwise move them to the palm detection
code instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This pen has random timeouts, often when a button is pressed. This causes a
forced proximity out (and the button release) and makes the whole device a
tad unusable.
Nothing we can detect by heuristics since it looks like other devices that
don't send proximity out events. And the timeout can be quite high, the
recording in #304 has over 800ms for one sequence.
Fixes#304
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where the proximity out event is delayed by the kernel, libinput would cause
an extra proxmity in-out after the forced proximity out event.
Event sequence is basically (k: kernel, l: libinput)
k: tablet axis events
l: tablet axis events
k: nothing for $proximity timer milliseconds
l: tablet proximity out
k: proximity out event
l: proximity in event
l: proximity out event
Fixes#306
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We only ever set properties in the devices, so let's make that more explicit
and auto-generate the udev rule. This way we're hopefully better protected
from the various typos that hid in those rules over the years, but also be
prepared for passing the udev property key/value pairs elsewhere.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This escaped us before because the MOUSE_DPI setting on the low-dpi device was
ignored thanks to a broken udev rule (see a future commit for that).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of value * 256 which makes for bad debug messages, expand it to a full
double test with a 1/256 epsilon.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
