config.set10 is much more convenient and nicer to read but can provide
false positive if the value is 0 and #ifdef is used instead of #if. So
let's switch everything to use #ifdef instead, that way we cannot get
false positives if the value is unset.
Closes#1162
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1277>
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>
Mixup of #if vs #ifdef caused this condition to always be treated as
true, resulting in leakage of key codes to the logs if the libinput log
level was set to debug.
Fixes: 7137eb9702 ("plugin: add ability to queue more events in the evdev_frame callback")
Closes#1163
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1276>
Our CI pipeline fails 9 times out of 10 on the valgrind tests. The tests
seem to finish in either 35 min or exceed the 60 min timeout limit, with
nothing in between. To avoid this let's split into more groups so we can
a) run those more in parallel and b) are less likely to hit the
timeout when run slowly.
Analysis of recent logs shows the eraser button tests to be the worst
offender, taking 752s (due to the combinatorial explosion) alone. The
various tip and proximity tests together also take some time so let's
group those out.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1274>
The vm tests had a 20 min timeout and a multiplier of 100. Our CI will
kill us (without logs) after 60 minutes.
Let's drop this to ~18min and a multiplier of 3 which gives us a few
minutes for setup before the CI terminates us. Ideally this means
we get some meson logs on timeout failures.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1274>
Fixes a regression causing missing scroll events on devices where the
kernel only sets REL_WHEEL/REL_HWHEEL but not the corresponding
hires events. On those devices we would get the legacy axis events but
no longer the new ones.
The mouse wheel plugin will correctly emulate missing hires events
but it doesn't attach to devices where the hires bit is never set.
This plugin can be very simple - since we know we enabled the code on
this device we don't need to keep any extra state around. If our frame
handler is called for this device we want to add the hi-res events.
Theoretically this breaks if the device has only one hi-res axis enabled
but not the other one (i.e. REL_WHEEL_HI_RES but only REL_HWHEEL) but
that's too theoretical to worry about.
Closes#1156
Fixes: 31854a829a ("plugin: only register the wheel plugin on devices that have a wheel")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1268>
mtdev is used only for MT Protocol A device of which there are quite
few. But that protocol is also a perfect example for event frames in ->
different event frame out so let's move this into the plugin pipeline.
Because the plugin doesn't really have full access to the device's
internals we set up mtdev base on the libevdev information rather than
just handing it the fd and letting it extract the right info.
A minor functionality change: previously mtdev-backed devices returned
zero on libinput_device_touch_get_touch_count(). Now it is hardcoded to
10 - the number of callers that care about this is likely near zero.
Because it's now neatly factored out into a plugin we can also make
mtdev no longer a strict requirement.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1245>
This makes event handling easier where plugins queue other event frames
per frame. Our initialization guarantees that our evdev code is alway
the last plugin in the series so in the no-plugin case we just pass on
to that.
The effective event flow is now:
evdev.c -> plugin1 -> plugin2 -> evdev-plugin.c -> evdev.c
except that no plugins exist yet.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1217>
This adds the scaffolding for an internal plugin architecture. No such
plugin currently exists and any plugin implemented against this
architecture merely is plugin-like in the event flow, not actually
external to libinput.
The goal of this architecture is to have more segmented processing
of the event stream from devices to modify that stream before libinput
ever sees it. Right now libinput looks at e.g. a tablet packet and then
determines whether the tool was correctly in proximity, etc.
With this architecture we can have a plugin that modifies the event
stream that the tool is *always* correctly in proximity and the tablet
backend itself merely needs to handle the correct case.
The event flow will thus logically change from:
evdev device -> backend dispatch
to
evdev device -> plugin1 -> plugin2 -> backend dispatch
The plugin API is more expansive than we will use immediately, it is the
result of several different implementation branches that all require
different functionality.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1217>
In addition to the evdev_frame this struct is what contains our actual
events instead of a struct input_event. The goal of this is twofold:
slightly better memory usage per frame since we can skip the timestamp
and refer to the evdev frame's timestamp only. This also improves
handling a frame since we no longer need to care about updating
all events when the timestamp changes during appending events.
Secondly it merges the evdev type + code into a single "usage"
(term obviously and shamelessly stolen from HID). Those usages
are the same as the code names but with an extra EVDEV_ prepended,
i.e. EV_SYN / SYN_REPORT becomes EVDEV_SYN_REPORT.
And they are wrapped in a newtype so passing it around provides
some typesafety.
This only switches one part of the processing over, the dispatch
interfaces still use a struct input_event
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1215>
Sadly, this detection was broken because in C everything defaults to
type int. Casting a const char* to int is permitted but generates a
warning which was promptly ignored by meson.
This result in HAVE_C23_AUTO being set on compilers that don't by
default have -Werror=implicit-int and "auto" ended up being just an
"int".
Change the detection to use gmtime() which returns a struct, and add a
basic test using one of our struct-returning utility functions, just to
be sure.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1198>
C23 auto is basically __auto_type so let's wrap it if our compiler
doesn't provide it (yet).
This lets us use `auto` as type specifier, e.g. compare
enum libinput_config_status status = libinput_device_config_set(...)
auto status = libinput_device_config_set(...)
Note that as of now meson will never detect this as it requires -std=c23
to be passed to the compiler. This flag is only supported by Clang 18
(released 2024) and we don't want to break things for older compilers
for what is a bit of a niche feature right now.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1181>
Instead of having this ifdef'd out split the main and directly
associated functions out into a separate file.
That ifdef used to exist so we can use parts of litest in some other
files (the selftest and the utils test). Those tests care mostly
about the assertion helpers so long-term a split into
assert helpers and "rest of litest" would be better. For now, this will
do.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1174>
A tablet with multiple mode toggle buttons had each mode toggle button
merely cycle to the next mode in the sequence, removing the whole point
of having multiple toggle buttons.
Fix this by defaulting each mode toggle button to "next". Once we
have initialized all buttons we can check if we have multiple buttons -
if so we number them sequentially so that the first button maps to mode
0, the second maps to mode 1, etc.
Closes#1082
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1132>
These have been behind #if 0 for ages but there are more to come, let's
make it possible to toggle those on/off with a meson option.
This is an option that must not be used in a release build, it will leak
key codes to the logs.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1156>
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>
These take a long time and have a reasonable high chance of failure due
to the timing constraints. Let's split them up so they don't hog the
runners for that long and in case they fail, we only need to re-run a
short test.
Before: one test running approx 21 min, now 3 tests running approx 7 +
11 + 4 min.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1065>
