The code in libinput-plugin-lua.c filters udev properties with
strstartswith(key, "ID_INPUT_") which requires a trailing underscore.
The bare 'ID_INPUT' property does not match this filter and is never
included in the properties table provided to plugins.
Co-authored-by: Claude <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1469>
The --multiple flag is deprecated and a no-op in the current code
(libinput-record.c). Multiple devices can simply be specified as
arguments on the commandline. Update the documentation to reflect
the current usage.
Co-authored-by: Claude <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1469>
The example output showed 'Name: /dev/input/eventN' but the actual code
(libinput-replay.py) prints '/dev/input/eventN: Name'. Update the
example to match the actual output format.
Co-authored-by: Claude <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1469>
ClickPads support both two-finger scrolling and edge scrolling, not
two-finger scrolling only. The code in evdev-mt-touchpad.c always
includes LIBINPUT_CONFIG_SCROLL_EDGE in the supported methods and adds
LIBINPUT_CONFIG_SCROLL_2FG if the touchpad supports 2+ touches.
Co-authored-by: Claude <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1469>
The simplified table showed 'Finger 1 down' producing '<no event>' but
all the detailed examples later in the same document show that a single
finger down triggers a hold begin event with finger count 1, followed by
a cancel and new begin when the second finger arrives. Update the
simplified table to be consistent with the detailed examples and the
actual implementation.
Co-authored-by: Claude <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1469>
There is no LIBINPUT_EVENT_GESTURE_HOLD_UPDATE event in the API.
When a finger is detected as thumb/palm during a hold and other fingers
remain, the implementation cancels the current hold and starts a new one
with an updated finger count. Update the documentation to describe the
actual behavior.
Co-authored-by: Claude <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1469>
If drag-lock is disabled but we're in a tap-and-drag state and the
finger is released near the edge (within 5mm), enable automatic drag
lock for 400ms. This allows a user to quickly reset the finger and
continue with the drag.
The 400ms is a randomly guessed timeout - if you're using tap-and-drag
without draglock, finger dexterity should be high enough that resetting
the single finger can be done quickly but it's also short enough to not
make the occasional delayed button be painful in day-to-day use.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1447>
Instead of adding a new ENABLED_HOLD enum value, modify the existing
ENABLED lock mode so that hold+scroll+release doesn't engage the lock.
Add a 500ms grace period: if the button was held and used to scroll for
longer than 500ms, releasing the button does not engage the lock
(temporary scroll). If released within 500ms (e.g. shaky hands
triggering accidental motion), the lock still engages as before.
This fixes the unintuitive behavior where the lock engages even after
actively scrolling, without requiring new API surface.
Closes: https://gitlab.freedesktop.org/libinput/libinput/-/issues/1259
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1435>
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>
The existence of the log global was in part due to early (pre-merge)
versions of the Lua plugins supporting multiple libinput plugin objects
per file. This is no longer the case and integrating the log functions
into the (single) libinput object makes the code more obvious (we're
calling libinput:log_debug() now, so it's obviously a libinput log
function) and we no longer mix dot with colon notations.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1350>
Injecting frame was the first implementation of adding event frames but
it has since effectively been replaced by append/prepend_frame which are
more predictable and easier to support.
In the Lua API injecting frames was only possible within the timer and
the only real use-case for this is to inject events that are then also
seen by other plugins. But that can be achieved by simply ordering the
plugin before the other plugins and using the append/prepend approach.
Until we have a real use-case for injecting events let's remove the API
so we don't lock ourselves into an API that may not do what it needs to
but needs to be supported for a long time.
Closes: #1210
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1351>
Because our lua hooks don't expose the device-added callback we need to
cache any calls to disable a feature and then apply it quietly when the
device is actually added. Any other call can go straight through.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1249>
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 adds the public API to configure an eraser button on a tablet tool
to emulate a normal button. In DEFAULT mode the eraser button will
simply do whatever it does by default (i.e. toggle to eraser).
In BUTTON mode the eraser button will be converted to a regular tool
button event, with libinput handling the underlying proximity event
madness.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1218>
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>
We don't have an API for "device really should have tapping enabled" so
right now the only indicator of whether that's the case is when the
device has tapping enabled by default. This kind of prevents us from
switching the default, so let's at least link to the comment explaining
this.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1115>
This adds the configuration option to define a rectangle that serves as
an input area on external tablets such as an Intuos.
The intention behind this is to make this input area behave as if it was
the only physical input area on this tablet with libinput emulating
proximity events as required for where the tools moves in and out
of this area.
This could also be achieved with the existing calibration setting but
area configuration is not calibration and we don't want to expose other
side-effects of the matrix (e.g. scaling and rotation) for these
devices.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
