If the tilt angle on tip down is not 0 set the touch arbitration to a
rectangle around the assumed position of the hand. This assumed position is
right of the tip for a rightwards tilt and left of the tip for a leftwards
tilt (i.e. left-handed mode). The rectangle is 200x200mm with a 20x50mm
NW of the tip or NE for left-handed. In other words, if the period below is
the tip, the rectangle looks like this:
+-----------+ +-----------+
| . | <- for rightwards tilt | . |
| | | |
| | | |
| | for leftwards tilt -> | |
+-----------+ +-----------+
Touches within that rectangle are canceled, new touches are ignored. As the
tip moves around the rectangle is updated but touches are only cancelled on
the original tip down. While the tip is down, new touches are ignored in the
exclusion area but pre-existing touches are not cancelled.
This is currently only implemented in the fallback interface, i.e. it will
only work for Cintiqs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When a hand is resting on a pen+touch device, lifting the hand may remove the
stylus from proximity before the hand leaves the surface. If the kernel
performs touch arbitration, this triggers a touch down on proximity out,
followed by a touch up immediately after when the hand stops touching.
This can cause ghost touch events. Prevent this by using a timer-based
arbitration toggle.
Same as 2a378beab0 but for the fallback
interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This leaves a bug open, on a Lenovo T440 generation touchpad with top software
buttons, the button will not be leased correctly. This is caused by
device->is_suspended=true by the time we try to clear the state and the
button events thus getting filtered.
This used to affect all touchpads, this patch just moves it so it only affects
the T440-like devices now.
Fixes#233
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Probably covered elsewhere in a more generic test anyway but let's have one we
know is executed for all touchpads.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a middle-button-emulating device is removed with one button down, the timer
never gets cancelled and triggers an assert during device removal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After the test device was removed, run one more libinput_dispatch(). This may
catch some errors that happen due to the device removal that were ignored for
now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
An emulated button is recorded as BTN_MIDDLE in the key down mask. If the
device is removed in that state, the BTN_MIDDLE event processed triggers
an assertion when we try to send out the event twice.
Fixes#201
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a device was removed while a button was held down and within the timeout,
the timer was never cancelled (and removed from the timer list), triggering an
assert during device removal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't check for correctness in the output as such, just that whatever
combination of cmdline arguments still works/doesn't work. This is the
scaffolding and a few tests, but needs to be filled in, especially for
libinput measure and for some more complex combinations.
valgrind: requires one more python-related suppression
gitlab-ci: requires another environment variable so we know to skip the
--device tests (udev will time out on those)
meson: skip the test run in release builds, we pass the full path to the built
libinput tool but rely on the subtool lookup that won't work in a
release build
Fixes#174
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
test/test-misc.c:1065:28: warning: Value stored to 't' during its
initialization is never read
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a more flexible approach than adding a model flag and the C code to
just call libevdev_disable_event_code(). There's a risk users will think this
is is a configuration API but there are some devices out there (e.g. the
Microsoft Sculpt mouse) that need a more generic solution.
Case in point: the Sculpt mouse insists on holding BTN_SIDE down at all times.
We cannot ship any quirks for that device because we only have the receiver's
generic VID/PID. So a local override is required, but we might as well make
that one generic enough to catch other devices too in the future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least on MacBooks, the host emulates two clicks 8ms apart in response to a
doubletap. Those clicks are filtered by our debouncing code.
Since these are emulated devices anyway and by definition cannot have a stuck
button, let's tag them so we don't enable the debouncing code. If the button
of the physical device is stuck, that's a problem that needs to be fixed in
the host system.
Fixes#158
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a 2fg scroll motion starts with both fingers in the bottom button area and
one finger moves into the main area before the other, we used to send motion
events for that finger. Once the second finger moved into the main area the
scroll was detected correctly but by then the cursor may have moved out of the
intended focus area.
We have two transitions where we may start sending motion events: when we move
out of the bottom area and when the finger moves by more than 5mm within the
button area. In both cases, check for any touches that are in the
bottom area and started at the 'same' time as our moving touch. Mark those as
'moved' to release them for gestures so we get the right finger count and
axis/gesture events instead of just motion events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The shape of the average hand implies that two fingers down within the lower
thumb area (the bottom few mm of the touchpad) cannot be thumbs without
significant contortion. So let's not mark them as thumb.
Fixes#126
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tp_detect_thumb_while_moving() assumes that of the 2 fingers down, at least
one must be in TOUCH_UPDATE, otherwise we wouldn't have a speed to analyze for
thumb.
If a touch starts in HOVERING and exceeds the speed limit, we were previously
increasing the 'exceeded count'. This later leads to an assert() in
tp_detect_thumb_while_moving() when the second finger comes down because
although we have multiple fingers, none of them are in TOUCH_UPDATE.
This only happens when fingers 2 and 3 come down in the same event frame,
because then we have nfingers_down at 2 (the hovering one doesn't count) but
we don't yet have a finger in TOUCH_UPDATE.
Fix this twofold, first by now calculating the speed on anything but
TOUCH_UPDATE. And second by force-resetting the speed count on
TOUCH_BEGIN/TOUCH_END so we definitely cover all the hover transitions.
Fixes#150
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When we disable the touch device, any existing touches should be cancelled,
not just released.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was removed accidentally as part of a9ef4ba1f3 and then completely dropped in
870ddce9e4 when the hwdb was deprecated completely. The model quirks call
is also the one that reads and sets the LIBINPUT_FUZZ property, effectively
making that code a noop.
Fixes#138
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We may get a pointer jump on tip down/up, see #128. For absolute coordinates
we reset the history to avoid smoothing across that jump but deltas still used
to be calculated based on the previous position to the current one. This
can result in a large jump on tip down.
Since the delta is supposed to be useful (and not physically accurate, see the
docs), let's force it to 0/0 on tip down/up to avoid that scenario.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because we're doing axis smoothing, we may get a nonzero delta between events
even when the real axis hasn't updated. Make sure the bit is set in this case.
One part of #128
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We never want to accidentally trigger this one. Where we trigger them on
purpose, we can swap the log handler out first.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This forces events for every ~10ms now. If we want a slower movement, we need
more steps - just like a real touchpad does it.
Cocinelle spatch files were variants of:
@@
expression A, B, C, D, E, F, G, H, I, J, K;
@@
- litest_touch_move_two_touches(A, B, C, D, E, F, G, H, I)
+ litest_touch_move_two_touches(A, B, C, D, E, F, G, H)
The only test that needed a real fix was touchpad_no_palm_detect_2fg_scroll,
it used 12ms before, now it's using 10ms so on the bcm5974 touchpad the second
finger was a speed-thumb. Increasing the events and thus slowing down the
pointer means it's a normal finger and the test succeeds again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Change a number of tests to use 10ms intervals between finger events and fix
the coordinates up accordingly to avoid pointer jumps. This is in preparation
for a test-suite wide use of 10ms intervals.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
move_to() now uses delays, let's make this test more robust for timing errors
so we don't fall below the threshold movement we want to trigger.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The coordinates ended up being in the first touch detected as palm. Not
relevant for this test, but let's not do that to avoid false positives.
Also change to 10ms intervals, more realistic given the hardware.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Once we start working with real event frames (i.e. intervals after SYN_REPORT)
we'll always trigger the proximity timeout here. Avoid this by sending one
event with all buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test only succeeded because all events were sent within the dwt timeout.
Change it to actually test the behavior of a touch being disabled by DWT and
staying disabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These only succeeded because the test suite doesn't use frame intervals - as
soon as the time between event frames is nonzero, we may fail these.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We can use the _extended version here. And it turns out the behavior was
slightly different, with the _extended version doing one step too few.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, we had a hard threshold of 20mm per event frame. That is just
about achievable by really fast movements (in which case you don't care too
much about the jumps anyway because you've already hit the edge of the screen).
Sometimes pointer jumps have lower deltas that are achievable even on slower,
more likely motions. Analysis of finger motion has shown that while a delta
>7mm per event is possible, jumping _by_ 7mm between two events is unlikely
and indicates a pointer jump. So let's diff the most recent delta and the
current delta, if it increases by 7mm between two event frames let's say it's
a pointer jump and discard it.
Helps with but does not fully resolve:
https://gitlab.freedesktop.org/libinput/libinput/issues/80https://gitlab.freedesktop.org/libinput/libinput/issues/36
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
