This patch adds a new API for enabling public "plugins" in libinput, in
addition to the exisitng internal ones. The API is currently limited to
specifying which paths should be loaded and whether to load them.
Public plugins are static, they are loaded before the context is initialized
and do not update after that.
If plugins are to be loaded, libinput will then run through those paths,
look up files and pass them to (future) plugins to load the actual
files.
Our debugging tools have an --enable-plugins and
--disable-plugins option that load from the default data paths
(/etc/libinput/plugins and /usr/lib{64}/libinput/plugins) and from
the $builddir/plugins directory.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1192>
The debounce, wheel/wheel-low-res, double-tool and eraser-button plugins can limit
themselves to a specific usage.
The mtdev plugin needs to pass each each event to mtdev and the proximity
timer plugin needs to get each event's timestamp so they cannot be
restricted.
The forced-tool could be restricted but effectively any event on the
devices it works on will have one of those usages set so there's no
point.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1271>
This adds the ability for a plugin to announce the evdev usages it may
possibly care about. Only event frames that contain one or more of those
usages will be passed to the plugin. Ideally this is an optimization
over calling every plugin for every frame but that largely also depends
on what exactly the plugin does with each frame.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1271>
Allows to keep track of a set of evdev masks, or at least the subset we
care about.
The EV_KEY range is split into two masks to save some memory. The future
use of this is for the plugins to use those masks and some of those will
set BTN_TOOL_PEN and friends. This would immediately create an 81 byte
mask of zeroes just to keep that one bit.
Splitting it into a key/btn mask with the latter starting at BTN_MISC
means we duplicate the infmask struct (2x16 bytes) but instead only use
8 bytes for the mask itself to keep the BTN_TOOL_PEN bits.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1271>
This test explicitly checks for devices only sending REL_WHEEL but *not*
REL_WHEEL_HI_RES. But that check only needs to run if the device has
the HI_RES axis.
The test device with REL_WHEEL_HI_RES disabled via quirk needs to be
special-cased since we cannot detect this in the test suite otherwise.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1284>
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>
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>
Same approach as chosen in libinput-record, this leaves the F1-F10 out
but otherwise prints every other "normal" key (including modifiers) as
KEY_A.
In the future we may need some more specific approach but for now this
will do. For the use-cases where we do need some specific approach,
libinput record and libinput debug-events will still show the full
keycode on request anyway.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1276>
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>
The plugin system prints all events before they're passed to the plugin
anyway and the special evdev plugin does not do anything but pass it on.
We can thus assume that the events passed to libinput are the same as
the ones passed to this plugin.
Let's do that and adjust the print format to be closer to what
evdev_log_debug() would print.
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>
This is a leftover from the Lua plugin branch where the question of
whether to have public plugins before or after internal plugins is a
valid one. We don't have public plugins here, so let's remove this
fixme.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1269>
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>
For mice with multipliers 30/120 and 40/120 nothing would change
as both will still cross threshold only after 2nd event.
But for MX Master 3 (and maybe others) that makes scroll beginning
a bit responsive, without jumping straight to 64/120 or 72/120.
Now events being emitted at 16+16+16 or 24+24 without significant
side-effects ("twitching" when resting finger on the wheel,
sudden scroll events when pressing middle button, etc). See !1262 for
some background.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1267>
The MX Master 3 is difficult, its wheel events are all over the place
and heuristics are tricky to determine. The previous plugin behavior
was seemingly sufficient for the MX Master but not for other devices.
Restore the old behavior if the quirk is set for a device by adding a
fourth state ALWAYS_ACCUMULATE. In this state the min movement is never
updated from the original threshold, causing any wheel motion to
accumulate.
Ref: ca6b82841c ("plugin/wheel: tighten the wheel debouncing code")
Ref: bb05e0d1b5 ("plugin/wheel: don't accumulate for low HID resolution multipliers")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1262>
