A few devices have a keyboard/keypad which can be slid under the device,
leaving the device with only touch-based interaction. The corresponding kernel
event is reported as SW_KEYPAD_SLIDE [0]. Implement support in libinput.
Since the position of the switch varies across devices, it cannot always be
certain whether the keypad is usable when the switch is in the set position.
Therefore, do not automatically disable the keyboard.
[0] e68d80b13b/include/linux/linux/input-event-codes.h (L885)Closes: #1069
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1242>
While luajit seems to be the most popular (and fastest) lua
implementation for higher-level implementations, at the system level
it is relatively unused. Lua 5.4 on the other hand is used by other
system-level components like wireplumber and RPM. In the latter case
this means that lua is already available on every rpm-based distro
without further dependencies.
The performance of 5.4 seems to be acceptable and while luajit may be
faster the extra dependency requires more maintenance. Let's only expose
ourselves to that if absolutely needed.
This is not a strict revert because the code has changed a bit since
with several bugfixes deployed on top.
This reverts commit 2723cadaeb.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1366>
Add an option to enable autoloading plugins from the default paths.
This makes testing and adoption for new users easier as they can (if
necessary) rebuild libinput with that option enabled instead of having
to wait for the compositor stack to update.
Autoloading will only use the default paths (/etc and /usr/lib) and will
only happen if the client does not modify those paths since that implies
the client wants to load plugins themselves. A client that adds a plugin
path but doesn't load the plugins is considered buggy anyway.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1347>
This patch adds support for Lua scripts to modify evdev devices and
event frames before libinput sees those events.
Plugins in Lua are sandboxed and restricted in what they can do: no IO,
no network, not much of anything else.
A plugin is notified about a new device before libinput handles it and
it can thus modify that device (changes are passed through to our libevdev
context). A plugin can then also connect an evdev frame handler which
gives it access to the evdev frames before libinput processes them. The
example plugin included shows how to swap left/right mouse buttons:
libinput:register({1})
function frame(device, frame)
for _, v in ipairs(frame.events) do
if v.usage == evdev.BTN_RIGHT then
v.usage = evdev.BTN_LEFT
elseif v.usage == evdev.BTN_LEFT then
v.usage = evdev.BTN_RIGHT
end
end
return frame
end
function device_new(plugin, device)
local usages = device:usages()
if usages[evdev.BTN_LEFT] and usages[evdev.BTN_RIGHT] then
device:connect("evdev-frame", frame)
end
end
libinput:connect("new-evdev-device", device_new)
A few other example plugins are included in this patch
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1192>
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>
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>
