Could be fixed in the kernel, but these tablets are effectively abandoned and
fixing them is a one-by-one issue. Let's put the infrastructure in place to
have this fixed once for this type of device and move on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Yay-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Simplest implementation for what we need right now, it turns off an event on
the evdev device and turns it back on again. This allows us to change bits in
the 'normal' event stream, such as changing the tool type without triggering
proximity events for the BTN_TOOL_PEN that all test devices send by default.
This won't work for absolute devices because we need to re-enable with a
struct input_absinfo. But we don't need that ability for now anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't initialize click methods on devices with physical buttons. This model
is a special case, it's not a clickpad but it only has one button (because one
button is all you ever need and whatnot).
https://bugs.freedesktop.org/show_bug.cgi?id=99283
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These tablets only ever give us a close event, the open event is broken. So
when we detect keyboard events, fix the kernel device's state by writing the
event to the fd.
We still sync the lid state manually, in case this fails and we don't get the
SW_LID through the normal event sequence. If it works fine, the real open
event will just be ignored.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, just enables us to use 'continue' instead of piling up
negated conditions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Right now, we fail if we call litest_push_event_frame() when already inside a
frame. For the semi-mt handling we need to do exactly that though, so turn it
into a counting semaphore instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As we switch to pressure-based touch detection, we need for all
pressure-capable touchpads to send pressure values. They'll do so by filling
in an axis default but that breaks our current hover code.
Make sure the hover litest helpers force a pressure of 0.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ship a custom udev rule for the test device until systemd v333 is commonplace.
Signed-off-by: James Ye <jye836@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
