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>
Instead of just waiting for events, use a libinput_dispatch() and assume the
event is there when we want it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This explains the heisenbugs when running the test suite. libevdev gives us
the syspath to the /sys/.../input123 node, not the one for the event node.
The device node path is created based on the sysfs tree, so there's a
window where the device node may not exist yet but we already returned the
device node path.
In litest, we're using a udev monitor to wait until the device is ready for
us, but the path interface only takes a device node path. So what happens is:
* libevdev gives us a syspath for the input node and a device path
* the monitor receives the input node udev device and matches the syspath
* we pass that up to the caller litest_add_device_with_overrides()
which opens the device node and adds it to libinput
* the path interface creates a udev device from the device node, which still
points to the old device node. Things fail because we don't have the device
we expect or it doesn't send events and eventually times out [1].
The errors triggered by this are either odd udev property mismatches or
timeouts because events are never processed.
This race is fixed by simply constructing the actual device node path we
expect from the udev device and waiting for the right device.
[1] We rely on the caller to notify us when to remove the device and thus
silently ignore ENODEV.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On unreliable tablets (Surface3), always force the lid switch to open when the
paired keyboard is removed. This way the lid can't be stuck in a closed state
when there's nothing attached that can actually trigger that state.
https://bugs.freedesktop.org/show_bug.cgi?id=101100
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On unreliable LID switches, we might have the LID declared as closed
while it is actually not. We can not wait for the first switch event to setup
the keyboard listener: it will never occur.
https://bugs.freedesktop.org/show_bug.cgi?id=101099
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having a litest_wait_for_event_of_type() in there causes us to silently
discard anything but the events we're looking for. This is risky, we want to
make sure that if we re-enable the lid that the key events arrive *after* the
lid open event, not before. So let's not paper over those.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We were checking for the empty queue on the wrong context, the default context
got drained a few lines above.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is most likely the first error message a developer encounters when
running the test suite and the /run/udev/rules.d directory already exists.
Make it more meaningful than the current generic integer comparison failure.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This function used to be called inside a test run a long time ago but moved to
a pre-setup stage without switching to the more generic litest_abort_msg.
The only error message we got is "check_msg.c:80: No messaging setup".
https://github.com/libcheck/check/issues/18#issuecomment-301217615
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We never installed the device groups file for the tests, effectively relying
on a system copy to be installed already.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was originally left outside of the button areas in case users tap in
those zones, but we're getting false tap events in that zone.
On a 100mm touchpad, the edge zone is merely 5mm, it's acceptable to ignore
taps in that area even in the software button. We can revisit this if we see
tap detection failures in the future.
https://bugzilla.redhat.com/show_bug.cgi?id=1415796
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Running through mesontest also runs parse-hwdb through valgrind and
gives us a bunch of leaks that originate within Python somewhere - we don't
care about those.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Running valgrind through mesontest produces coredumps for a lot of tests
(unclear why, the core dump merely shows a call to abort). But even without
mesontest, creating a core dump for each failed test is a bad idea - if one
fails, most likely many others fail and the coredumps quickly fill up the file
system.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the event listener is added, then removed again on a lid switch on/off
event, the list is set to null. This can trigger two crashes:
* when the keyboard is removed first, the call to
libinput_device_remove_event_listener() dereferences the null pointer
* when the switch is removed first, the call to device_destroy will find a
remaining event listener and assert
https://bugzilla.redhat.com/show_bug.cgi?id=1440927
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Sequence triggered by the xorg driver, but basically: if the touchpad is
destroyed before the lid switch, the event listener wasn't removed and an
assertion was triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We use #if everywhere else and it allows building with '-Wundef -Werror=undef'
to avoid accidental misuse.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With autotools, we replace the @top_srcdir@ during configure and then run teh
resulting scripts.
With meson, it's easier to just pass top-srcdir it in as argument.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
test-tablet.c: In function ‘proximity_in_out’:
test-tablet.c:797:20: warning: increment of a boolean expression [-Wbool-operation]
have_tool_update++;
And tighten the test so we fail for multiple prox in events
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
check 0.11 has those macros, but they don't work the same way as our homemade
ones. So for now just #undef them
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes the tapping times shorter and hopefully more obvious. It also fixes
a bug where repeated tripletap (by tapping with one finger while leaving the
other two down) could cause incorrect timestamps.
https://bugs.freedesktop.org/show_bug.cgi?id=100796
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For multitap, we're one tap behind with the button clicks, i.e. we send the
first full click button on the second tap, etc. Remember the timestamps of the
touches so we can send the events with the right timestamps. This makes
tapping more accurate because the time between taps and various timeouts
matter less for double-click detection.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Without this enabled, we stay in the single/double tap part of the state
machine and a triple tap is just a double tap followed by a single tap.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Try to guess the default scroll buttons a bit better. Right now we default to
scroll button 0 (disabled) whenever a device doesn't have a middle button but
we might as well cast a wider net here as setting a scroll button only has a
direct effect when button scrolling is enabled.
Use the first extra button we find or fall back onto the right button if we
don't have any extra buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As of systemd commit f013e99e160f385a0c02793c612ef4c8a8ffc4d7, ID_BUS is now
set for all bluetooth devices, not just those with subsystem bluetooth. This
affects the Apple Magic Mouse and sets the systemd hwdb's MOUSE_DPI value.
That value is different to the test results we currently have, causing some
tests to fail because different deltas are generated (e.g.
pointer_scroll_button).
Our udev rules are prefixed 99 and thus apply after the various system rules.
So we can't easily set ID_BUS in our rule because it'll apply after
70-mouse.rules checks for the bustype. So we'd have to detect systemd version
or so, but the easy way is to simply force MOUSE_DPI to the empty value. For
our test cases it doesn't matter if the DPI is set correctly anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a single log message is composed of multiple calls (as are all from
evdev_log_*), don't prefix multiple times.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
