In commit 9a9466b6a9 ("evdev: discard any frame with EV_SYN SYN_REPORT 1")
all frames with a SYN_REPORT 1 were discarded on the assumption of those
being key repeat frames. Unfortunately the kernel uses the same sequence
to simply mark *any* injected/emulated event, regardless of the cause. Key repeat
events are merely the most numerous ones but as shown in commit
7140f13d82 ("evdev: track KEY_SYSRQ frames and pass them even as repeat frames")
Alt+PrintScreen is also an emulated event.
Issue #1165 details another case: keyboards with n-key rollover can
exceed the kernel-internal event buffer, typically 8 events for devices
without EV_REL/EV_ABS. Those events will be broken up by the kernel into
multiple frames - once nevents == buffer_size the current state is
flushed as SYN_REPORT 1 frame. Then, if any more events are pending
those are flushed as SYN_REPORT 0 frame. In the case of exactly 8
events, the second frame is never present, so we cannot easily detect if
another one is coming.
Issue #1145 only affects us in the touchpad code, the rest of the
backends seem to (so far) be fine. So let's move the discarding of
SYN_REPORT 1 to the touchpad backend and leave the rest of the code
as-is.
This effectively
Reverts: 7140f13d82 ("evdev: track KEY_SYSRQ frames and pass them even as repeat frames")
Reverts: 9a9466b6a9 ("evdev: discard any frame with EV_SYN SYN_REPORT 1")
Closes#1165
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1282>
Make sure we drop any potential high-resolution wheel events from a
device that isn't supposed to have them.
Where the device's axes were disabled due to a quirk, re-enabling the
axes means the device's events won't be filtered anymore. Our wheel
emulation plugin thus emulates high-resolution wheel events in addition
to the hardware events.
Fix this by simply filtering out any high-resolution wheel events on any
device that uses this plugin.
Closes#1160
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1279>
If we push/pop event frames and combine various functions we might end
up sending the same value in the same frame multiple times. This
*should* be fine with libinput but is different to what the kernel does
in that case and harder to debug.
Let's batch any litest_event() until an EV_SYN arrives, then write them
all to libinput in one go.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1187>
This avoids inconsistencies between the LITEST_ enum value and the
shortname but also makes it easier to grep for any test cases that use
the same define. At the cost of the test names not looking very nice
anymore but oh well.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1157>
Exposed via new configuration option this enables 3 and 4 finger
dragging on touchpads. When enabled a 3/4 finger swipe
gesture is actually a button down + motion + button up sequence.
If tapping is disabled the drag starts immediately, if tapping is
enabled the drag starts after the tap timeout/motion so we can distinguish
between a tap and a drag.
When fingers are released:
- if two fingers remain -> keep dragging
- if one finger remains -> release drag, switch to pointer motion
When 3/4 fingers are set down immediately after releasing all fingers
the drag continues, similar to the tap drag lock feature. This drag lock
is not currently configurable.
This matches the macos behavior for the same feature.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1042>
litest supports ranged tests but they are not enough, doubly so with
tests where we want to parametrize across multiple options.
This patch adds support for just that, in clunky C style.
The typical invocation for a test is by giving the test parameter
a name, a number of values and then the values themselves:
struct litest_parameters *params = litest_parameters_new("axis", 's', 2, "ABS_X", "ABS_Y",
"enabled", 'b', '2', true, false,
"number", 'u', '2', 10, 11,
NULL);
litest_add_parametrized(sometest, LITEST_ANY, LITEST_ANY, params);
litest_parameters_unref(params);
Currently supported are u (uint32), i (int32), d (double), b (bool),
c (char) and s (string).
In the test itself, the `test_env->params` variable is available and
retrieval of the parameters works like this:
const char *axis;
uint32_t number;
bool enabled;
litest_test_param_fetch(test_env->params,
"axis", &axis,
"enabled", &enabled,
"number", &number,
NULL);
Note that since this is an effectively internal test-suite only
functionality we don't do type-checking here, it's assumed that if you
write the code to pass parameters into a test you remember the type
of said params when you write the test code.
Because we don't have hashmaps or anything useful other than lists the
implementation is a bit clunky: we copy the parameter into the test
during litest_add_*, permutate it for our test list which gives us yet
another linked list C struct, and finally copy the actual value into
the test and test environment as it's executed. Not pretty, but it
works.
A few tests are switched as simple demonstration. The name of the
test has the parameters with their names and values appended now, e.g.:
"pointer:pointer_scroll_wheel_hires_send_only_lores:ms-surface-cover:axis:ABS_X"
"pointer:pointer_motion_relative_min_decel:mouse-roccat:direction:NW"
Filtering by parameters can be done via globs of their string
representation:
libinput-test-suite --filter-params="axis:ABS_*,enabled:true,number:10*"
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1109>
This replaces check. The code is a copy of pwtest which I wrote years
ago for pipewire but adjusted for us here the last few days.
There are a few advantages over check:
- Ability to SKIP tests or mark them as NOT_APPLICABLE, the latter
of which is used for early checks if a device doesn't meet
requirements.
- it captures stdout/stderr separately
- colors!
- YAML output format makes it a lot easier to read the results and
eventually parse them for e.g. "restart failed tests"
Less abstraction: we set up the tests, pass them to the runner and run
them with the given number of forks. This is an improvement over before
where we forked into N test suites which each called check which then
forked again. Since we're now keeping track of those processes
ourselves we can also write tests that are expected to fail with
signals.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1067>
