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>
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>
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>
90% of failed valgrind jobs are caused by a race condition when a runner
is too slow. Instead of waiting for someone to click the retry button
let's just retry immediately again.
This could be fine-tuned to check for valgrind errors vs test suite
errors but for now this should do.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1257>
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>
vng is much faster than b2c for spinning up the jobs, so better use this
instead.
Bonus point: we don't need the start-in-systemd.sh stunt.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1125>
It's a bit annoying to only find those during a CI pipeline run, so
let's add a hook for it. Pre-commit doesn't seem to have something
useful for duplicate line detection so let's hack up a quick script
that can do this for us, together with the other whitespace checks in
the CI so we're consistent.
Excluded from the duplicate line checks are anything "Not C" and the
"include/" directory since we don't control those files.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1154>
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>
Instead of extracting the suite name from the test's file name use the
current suite that is being parsed. This way we pave the way for
multiple suites in the same file.
This uses a global because otherwise we'd have to redo all the
litest_add() functions but it does the job here.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1065>
marge-bot rebases and edits the commit message but there's not way for
it to introduce a memleak that wasn't spotted in the user pipeline
first. Since those tests are very flaky, let's skip them when running
the marge-bot pipeline.
Closes#1042
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1057>
Our valgrind jobs are very timing-sensitive so it's very common that
they fail with an error when the reason is just valgrind being slower
and we miss a deadline somewhere.
Retry them if they fail, hopefully that gives us more reliable
pipelines.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1040>
Actually libinput is one of the last users of harbor.fd.o, because it uses
an outdated version of vm2c.py. Use the new location of the project,
bump its release, and also bump the kernel version we test while at it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Meson recommends using the `meson setup [options]` command:
WARNING: Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated.
Update the documentation and CI to use the recommended command.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
We've had this for roughly 10y now and it's value is dubious. Most of
xorg no longer requires, mesa accepts but doesn't require it, most of GNOME
doesn't accept it and neither does systemd.
Let's drop the requirement.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
