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>
Touchpads that don't give us useful palm detection data are getting more
common (see e.g. our ABS_MT_TOOL_TYPE quirks). On those touchpads we can
only rely on dwt and palm edge detection which means those two must be
more spot on than ever before.
DWT in particular is more prone to user-specific requirements, the
current timeouts have been insufficient for a number of users. So let's
make them more configurable.
Currently limited to >100ms and <5 seconds to avoid DWT being used in
the xkcd workflow style.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1372>
If the device is unplugged, our tool's last_device is NULL. If a caller
then tries to the toggle the eraser button setting libinput would crash.
Fix this by simply skipping the configuration until the tool goes back
into proximity over some other device (if any).
Closes#1223
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1370>
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>
A caller is likely to unconditionally call
libinput_tablet_tool_config_pressure_range_set() with whatever
values it has in its config storage. Those values will be 0 and 1 by
default, we should not take this as a sign that the tool has a pressure
range.
Setting a pressure range resets the automatic offset handling which we
definitely don't want to do for the default range.
Fixes: #1177
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1340>
When a user configures a pressure range, the tool would get locked into
the current offset even if that offset was still pending. For example, a
sequence of
- tool in-prox with pressure 50%
- libinput_tablet_tool_config_pressure_range_set(tool, 0.0, 0.9)
- tool out-of-prox, tool-in-prox
- libinput applies the tool config, tool now has a configured range,
has_offset = true
- tool out-of-prox, tool-in-prox
- update_pressure_range() sees has_offset = true, scales the last offset
(50%) to the actual offset.
Fix this by resetting the detected offset to zero when we shortcut the
heuristics. A user-defined pressure range should include the tool's
pressure offset anyway, the user knows this much better than our
heuristics.
Closes: 1177
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1340>
"libinput_plugins_flags" is bound to be annoying to approximately
everyone who'll ever have to use them so let's rename this while we
still can. Renamed to libinput_plugin_system_flags to leave the
namespace open for a possible future libinput_plugin_flags that works
on individual plugins.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1337>
If a plugin adds events to an event frame that are not supported by the
target device we may eventually dereference a null pointer (for ABS_*
events) or, possibly, use an OOB index access (for buttons or keys).
Let's filter out any events that the device doesn't support immediately.
Fixes#1202
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1324>
A device may send axis events while the tool is out of proximity,
causing our plugin to force a proximity in for the pen. If the tool then
sends a proximity event for a different tool we ended up with two tools
in proximity.
The sequence in #1171 shows this:
- evdev:
- [ 1, 499608, 3, 27, 0] # EV_ABS / ABS_TILT_Y 0 (+30)
- [ 1, 499608, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms
- evdev:
- [ 2, 199637, 1, 321, 1] # EV_KEY / BTN_TOOL_RUBBER 1
- [ 2, 199637, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
- [ 2, 199637, 1, 330, 1] # EV_KEY / BTN_TOUCH 1
- [ 2, 199637, 3, 0, 910] # EV_ABS / ABS_X 910 (+246)
- [ 2, 199637, 3, 1, 8736] # EV_ABS / ABS_Y 8736 (-105)
- [ 2, 199637, 3, 27, -25] # EV_ABS / ABS_TILT_Y -25 (-25)
- [ 2, 199637, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +700ms
Fix this by remembering that we forced the tool out of proximity so if
we see tool events for another tool we force the pen out of proximity
again.
This will have some interplay with the other tablet plugins but
hopefully none that affect real-world devices, e.g. forcing a proximity
out means the proximity out timer plugin gets disabled. Since devices
behave in unexpected manners anyway let's see if it affects a real-world
device.
Closes#1171
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1306>
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 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>
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>
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>
Accumulating (and partially discarding) scroll wheel events serves to
debounce a scroll wheel and provide for more fluid scrolling where
scroll wheels can send events going in the wrong direction.
This is unlikely to happen on devices with low resolution multipliers
(i.e. where some significant physical movement by the wheel is required
to trigger events) so let's make it contingent on devices more likely to
have flaky wheels.
The magic threshold picked is 30 (HID resolution multiplier of 4) as a
guess. The resolution multiplier isn't accessible in userspace so we
have to heuristically get to it - typical interaction with a mouse will
have that value set within the first two, three scroll wheel events
though.
Closes#1150
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1261>
