Devices tagged as accelerometers may also be other devices like tablet pads.
Only ignore pure accelerometer devices but disable the accelerometer axes for
devices that have multiple types.
https://bugs.freedesktop.org/show_bug.cgi?id=102100
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
The current tests worked because all rings had the same range, so our error
margin covered for that. With the upcoming MobileStudio Pro 16 pad device, the
range is half and our error margins don't work anymore. Switch to a more
reliable approach that tests every integer value the wheel can send, even
though it relies on kernel filtering.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The recommended way to have libinput ignore specific devices so far was to
remove the ID_INPUT* properties from the device. That may also affect other
pieces of the stack that need access to this device.
For the niche case of a device that should only be ignored by libinput but
otherwise be treated normally by the system, we now support the
LIBINPUT_IGNORE_DEVICE property.
If the property is set to "0", it's equivalent to being unset. This gets
around some technical limitations in udev where unsetting a property is
impossible via a hwdb entry.
https://bugs.freedesktop.org/show_bug.cgi?id=102229
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And make it init the full litest device minus the libinput device. This
enables us to add litest devices that aren't handled by libinput.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't know the position of the third finger on 2-slot touchpads, differing
between swipe and pinch is reliable. Simply disable 3-finger pinch and always
use swipe; 3fg pinch is uncommon anyway and it's better to have one of the
gestures working reliably than both unreliably.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The lid dispatch interface is a one-trick pony and can only handle SW_LID. It
ignores other switches but crashes on any event type other than EV_SW and
EV_SYN. Disable those types so we just ignore the event instead of asserting.
https://bugs.freedesktop.org/show_bug.cgi?id=101853
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Some devices have worn-out switches or just cheap switches that trigger
multiple button events for each press. These can be identified by unfeasably
short time deltas between the release and the next press event. In the
recordings I've seen so far, that timeout is 8ms.
We have a two-stage behavior: by default, we do not delay any events but we
monitor timestamps. The first time a bouncing button is detected we switch to
debounce mode. From then on, release events are delayed slightly to check for
subsequent button events. If one occurs, the releas and press are filtered. If
none occurs, the release event is passed to the caller.
https://bugs.freedesktop.org/show_bug.cgi?id=100057
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the kernel sends us a button press for a button that is thought to be down
we have lost track of the state of the button. Ignore the button press event,
in the hope that the next release makes things right again.
A release event may be masked if another process grabs the device for some
period of time, e.g. libinput debug-events --grab.
https://bugs.freedesktop.org/show_bug.cgi?id=101796
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Switch to a pure factor with a max scaled after a function. The offset is just
0 now (will be removed eventually). Both are determined with a function based
on a linear/exponential regression of a sample set of data pairs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's no guarantee that libinput does the right thing if memory allocation
fails and it's such a niche case on the systems we're targeting that it just
doesn't matter. Simply abort if zalloc ever fails.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Apple touchpads don't use ABS_MT_PRESSURE but they are multitouch touchpads,
so the current pressure-based handling code doesn't apply because it expects
slot-based pressure for mt touchpads.
Apple does however send useful data for ABS_MT_WIDTH_MAJOR/MINOR, so let's use
that instead. The data provided in those is more-or-less random, so we need a
hwdb entry to track the acceptable thresholds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The max values on ABS_MT_TOUCH_MAJOR/MINOR aren't hard limits, they basically
represent the size of a finger with (afaict) a suggestion that anything
greater than the max may be a palm. Disable the 0-100% range checks for those
axes so we can send custom events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the keyboard is removed while dwt thinks it is in active state, that state
is never reset and subsequent touches are ignored.
https://bugs.freedesktop.org/show_bug.cgi?id=101743
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Uninitialized variables, potential NULL dereferences, dead assignments and an
unused return value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This reduces unexpected cursor moves when placing the thumb near the border
of trackpoint buttons and upper edge of touchpad.
https://bugs.freedesktop.org/show_bug.cgi?id=101574
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Already done in main(), this here is a leftover from having multiple mains fro
different tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was useful when we had a small number of test-forks with the suites
distributed. It helped debug which one is still running and then which suites
are in it. Now that we simply distributed everything across the forks it
doesn't have a lot of usefulness and it interferes with the ability to
backtrace properly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Broken since the merge of palm pressure detection in
25d54b90d, not sure why the test suite succeeded on that one nonetheless.
I'm not 100% sure why the test does what it does but it seems to be testing
that a wide touch on the side still striggers edge scrolling and not the thumb
detection on the bottom of the touchpad. That is obsolete now, it's hard to
generically figure out the small gap between thumb and palm pressure, so this
test almost always triggers palm detection. It's obsolete.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We used to completely ignore a finger that was within the top software button
area and then moved to the main area and remained there for a timeout. This
avoids erroneous pointer movements when the user moves the finger while using
the trackpoint.
But we also ignored physical clicks, something we should not be doing. This
patch fixes that behavior: we still ignore the finger for movement, but a
physical click now triggers a left click once we've been in the area for the
timeout.
This new behavior doesn't apply within the timeout, i.e. if a finger is in the
right top button area, moves out and immediately clicks, we still trigger a
right click. This avoids erroneous switches to left-clicks when the finger is
at the edge of the button area and moves out during the press.
Related to: https://bugs.freedesktop.org/show_bug.cgi?id=99212
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touch goes past the fixed pressure threshold it is labelled as a palm and
stays a palm. Default value is one that works well here on a T440 and is
virtually impossible to trigger by a normal finger or thumb. A udev property
is exposed so we can handle this in the udev hwdb and the new tool introduce a
few commits ago can help finding the palm detection threshold.
Unlike the other palm detection features, once a palm goes past the threshold
it remains a palm until the touch is released. This means palm overrides any
other palm detection features. For code simplicity, we don't combine the
states but merely check for pressure before and after the other palm detection
functions. If the pressure triggers, it will trigger before anything else. And
if something else is already active (e.g. edge where the pressure doesn't work
well) it will trigger as soon as the palm is released.
The palm threshold should thus be chosen with some room to spare between the
highest finger pressure.
https://bugs.freedesktop.org/show_bug.cgi?id=94236
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The check framework takes and stores the pointer and expects it to be live for
the livetime of the test but it doesn't strdup it. We have to keep those
pointers around ourselves.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Do so on the synaptics serial touchpads at least, they're known to cause
cursor jumps when the third finger is down. Not detecting a tap move means
three-finger taps get more reliable on these touchpads.
This change affects gestures who now effectively have to wait for the tap
timeout to happen. It's a trade-off.
https://bugs.freedesktop.org/show_bug.cgi?id=101435https://bugzilla.redhat.com/show_bug.cgi?id=1455443
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Check arranges the tests into suites and test cases (which then can have
multiple test functions). The primary feature for suites is the ability to
select them with environment variables and that the log messages are printed
per suite, not per test case.
We used the suites to distribute tests across the processes forked by the test
runner, but that also resulted in slow suites relying on timeouts (tap/dwt) to
take a lot longer than other suites and hold everything else up.
This patch basically drops the use of check test suites. Our test runner has a
--filter-group argument which selects on suite names, the log messages are
more useful if they immediately include the device and the test case name.
So we just save the test metatdata in our own struct and then assemble a
suite/test case on the fly for each test.
The advantage of this is that tests of the same suite are now distributed
across the forks so slow tests that rely on length timeouts are now run in
parallel. This brings the test runs down to under 6 min again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it possible to run multiple test suite simultaneously on the same
host without messing up the other runs (provided that all instances use
the same udev/hwdb files). Previously, removing the udev rules/hwdb at the end
of a test run would cause test case failures in other runs that hadn't
completed yet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
No internal timeout we have takes longer than 2s, so we can abort if we don't
succeed. This gives us a better backtrace to figure out where we're hanging
than the SIGABRT that check will eventually send us.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
