copy/paste error that makes coverity unhappy. This is the code to correctly
release all touches and the buttons have already been processed above - no
need to reassign here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Coverity complains that we call libinput_event_destroy() twice on the variable
(once in and once just outside the condition). This is technically correct but
never true because we always break the loop early for the touch up/frame events.
Let's just reset the pointers so coverity is happy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
x/y assigned but never used. Dropping those few lines gets rid of the warning
and checks the coordinates correctly now too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scroll button locking is an accessibility feature. When enabled, the scroll
button does not need to be held down, the first click holds it logically down,
to be released on the second click of that same button.
This is implemented as simple event filter, so we still get the same behavior
from the emulated logical button, i.e. a physical double click results in a
single logical click of that button provided no scrolling was triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Any touch down event will also provide motion data, but we must not send a
motion event for those in the same frame as the down event.
Fixes#375
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scrolling and gestures use unaccelerated motion. The idea behind it was that
at least for the default speed setting of 0, the accelerated speed and
unaccelerated speed are identical where meaningful.
The touchpad speed curve has a plateau for 'normal' speeds (i.e. not very slow
and not very fast) where the acceleration factor is constant. This is the
reference factor that the unaccelerated motion should use as well.
Since the touchpad acceleration rework in d6e5313497 the reference factor is
0.9 * TP_MAGIC_SLOWDOWN (previously the factor was 1.0 * TP_MAGIC_SLOWDOWN)
and scroll motion is thus 10% faster than the pointer movement at the default
speeds. Let's fix this and let the two match up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some graphics tablets (most or all Wacom, for example) do not emit
proximity out events when the tablet pen goes out of range. To
compensate for this, libinput synthesizes proximity out events when no
events are received for a certain period of time. Unfortunately, on some
tablets, this is fairly failure prone when moving the pen slowly. As a
workaround, this patch causes libinput to avoid synthesizing proximity
out events when the pen is still in contact with the tablet pad, as
defined by the TABLET_TOOL_IN_CONTACT status.
The udev_properties array is currently variable length, which causes the
tests to invoke undefined behavior on empty lists, as it attempts to
access the first array item to check if the key is NULL, which is an out
of bounds read and will fail when the struct alignment happens to line
up such that there is no padding after the list in the empty list case.
By making the udev_properties array 32 items long, it can encapsulate
every existing case, with only a fairly small amount of memory overhead,
and without requiring every single `TEST_DEVICE` call to initialize
`udev_properties`.
This used to work under valgrind up to F30 but with the F31 beta something is
now a tad slower so it triggers the timeouts before the middle emulation kicks
in.
The middlebutton timeout is 50ms and the first debounce timeout is 30ms, so if
we're late by 20ms, well, there goes the timeout.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where a fuzz is defined in the 60-evdev.hwdb, we rely on a udev builtin to
set the kernel device to that fuzz value. Unfortunately that happens after our
program is called with this order of events:
1. 60-evdev.rules calls IMPORT(builtin) for the hwdb which sets the EVDEV_ABS_*
properties. It also sets RUN{builtin}=keyboard but that's not invoked yet.
2. 90-libinput-fuzz-override.rules calls IMPORT{program} for our fuzz override
bits. That sets the kernel fuzz value to 0 and sets the LIBINPUT_FUZZ_*
propertie
3. The keyboard builtin is run once all the rules have been processed.
Our problem is that where the fuzz is set in a hwdb entry, the kernel fuzz is
still unset when we get to look at it, so we always end up with a fuzz of zero
for us and a nonzero kernel fuzz.
Work around this by checking the EVDEV_ABS property, extracting the fuzz from
there and re-printing that property without the fuzz. This way we ensure the
kernel remains at zero fuzz and we use the one from the hwdb instead.
Fixes#346
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libinput-util.h is getting a bit of a catchall bucket and it includes things
like libinput-private.h which in turn includes libwacom. This makes
libinput-util.h less useful for bits that only need e.g. the string processing
utilities.
So let's split them all up in to separate files, to be used as-needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These tests include string parsers, definitely want those to run under
valgrind to detect OOB reads and writes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allowing gestures when holding a physical click enables tasks like
switching workspaces while dragging an icon, but this should only be
possible with a *thumb* holding down the clickpad, not fingers. This
commit restores the ability to hold down the clickpad with two or three
fingers to right- or middle-drag.
Fixes#339, #340
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Pens that don't have a pressure offset (caused by a worn-out tip) still have
basic pressure thresholds to avoid tip events when we're still a bit away from
the tablet or barely touching it. That range is currently 5% of the pressure
for tip down, 1% for tip up.
This leaves us with 95% of the range and that needs to be scaled correctly,
otherwise the bottom 5% happen before a tip event and are inaccessible where
applications don't look at pressure before tip down.
Fixes#332
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Theoretically this shouldn't matter, but testing at the far end of the range
is bound to trigger some little issues eventually that should be triggered
explicitly, not by accident.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, the pressure range was calculated from the axis total range. A
device with a pressure offset making the bottom 10% inaccessible would lose
10% of that range as non-accessible. Due to the implementation, this affected
the upper range of the device, so the top N percent became unaccessible. Which
may be why no-one's noticed this yet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unsuprisingly, a normalized [0,1] value will always be between 0 and 1, so
bhis gave us a false positive. Check for the real values instead.
Those values aren't 100% correct because of a bug in the offset handling which
will be fixed in a follow-up commit. The difference is near enough that it
doesn't matter here anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In evdev_device_calibrate, the user matrix was not being stored when it
was the identity matrix. This resulted in
libinput_device_config_calibration_get_matrix not providing the correct
matrix. Instead of giving the identity matrix, the last non-identity
matrix set was given.
This just moves the storage of the user matrix in
evdev_device_calibrate to be above the identity matrix early return so
that it always get stored.
Signed-off-by: Brian Ashworth <bosrsf04@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We keep running into the proximity timeout for these tests, especially under
valgrind. To avoid this, manually intersperse the touch events with tablet
events.
Note that this manual loop would just work even without tablet events
because we no longer have a 10ms delay between touch events as enforced by
litest_touch_move_to. But let's do the right thing anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of a simple yes/no/maybe for thumbs, have a more extensive state
machine that keeps track of the thumb. Since we only support one thumb anyway,
the tracking moves to the tp_dispatch struct.
Test case changes:
touchpad_clickfinger_3fg_tool_position:
with better thumb detection we can now handle this properly and expect a
right button (2fg) press for the test case
touchpad_thumb_no_doublethumb_with_timeout:
two thumbs are now always two fingers, so let's switch to axis events here
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't need speed detection for non-clickpads - the only reason to ever drop
a second finger on those is to either scroll or trigger a gesture. Unlike
clickpads, where a dropped finger may be a thumb to click.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
