This recovers the testing that a USB keyboard plus touchpad combo both
set as external, only its own keyboard should affect to DWT that was
removed when Acer Hawaii combo was set as internal.
This is uncommon as usb touchpads nowadays are set as internal, but,
perhaps someone that adds a quirk for a really external combo also adds
in udev's hwdb the external integration for the touchpad, or perhaps we
should set the integration to external when AttrTPKComboLayout=below is
used for the touchpad.
The issue is if the touchpad is leave as internal every keyboard affect
DWT, not only the one that belongs to its combo.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1415>
This adds a movement threshold (5mm) and a timeout (80ms) to the 3fg
drag gesture. On 3fg down with 3fg drag enabled we immediately send a
GESTURE_SWIPE event. After the timeout expires we check the movement of
the fingers - if it is below the threshold cancel the swipe and hold a
button down (i.e. a 3fg drag). Otherwise, continue with this being a
swipe.
This allows for swipe gestures to be used while 3fg drag is enabled.
Above applies the same way for 4fg with 4fg drag enabled.
Thresholds selected using the "yeah, that seems about alright" method,
intentionally quite low because we assume that users that enable 3fg
drag prefer 3fg dragging over swipe.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1410>
Instead of disabling the touchpad as soon as a mouse is seen by
libinput, disable it as soon as a mouse sends an actual event. This
works around the current issues with many devices (touchpads and
keyboards alike) announcing a HID Mouse Application Collection which
gets its own event node in the kernel. That event node usually just sits
there and does nothing but its mere presence disabled the touchpad.
Let's change this and instead only disable once we see an event.
Closes: #1104
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1414>
If a lua pcall takes longer than one second, kill the plugin.
How often to call the timeout handler is a trade-off but we err on the
side of "possibly too high" since the overwhelmingly vast majority of
plugins will never trigger it anyway.
Gemini suggests that Lua 5.4 can do ~500k ops per second for string
concat (the slowest listed), Claude suggests 1 to 10 million ops per
second. The test in this patch on my 4y old cheap desktop runs the
timeout hook roughly every 37ms. Any normal plugin will be well and
truly done with its work by then.
Closes: #1245
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1416>
If the tool has a name let's provide that to the caller. We have it
easily accessible so let's export it to make everyone's life easier. The
name is provided by libwacom, there is no need for us
to even copy that value since we don't need it ourselves.
Note that at this point effectively only (some) Wacom devices have
meaningful names. Virtually all non-wacom devices will use a generic
tool and even the built-in Wacoms will largely just say "AES Pen".
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1399>
The WHEEL_STATE_NONE check was effectively always false:
- if we didn't receive any event yet, wheel_maybe_disable() wasn't
called in any code path
- if we did receive a scroll event, the wheel state was either
WHEEL_STATE_SCROLLING or WHEEL_STATE_ACCUMULATING_SCROLL
Fix this two-pronged: remove the check for WHEEL_STATE_NONE but also
immediately call disable when we disable the feature. We don't carry
enough state in this plugin to really worry about the device being in
a fully neutral state (and realistically the vast majority of use-cases
will likely disable wheel debouncing on new device anyway).
Closes#1241
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1408>
Actually all usb touchpads are internal by default, reflect this in the
acer touchpad definition.
This causes that not only the acer keyboard in its group activates DWT
but all the intenal keyboards.
Remove asserting that other keyboards doesn't affect DWT as that is the
intended behaviour.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1400>
Ifdef out any special behavior we want so we no longer leak this via
strings in the resulting binary. Ideally we want the compile to fail for
anything missed rather than surprising behavior when we try to access
files in the build directory.
Closes: #1230
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1396>
This tests for a known bug in the implementation rather than the ideal case
how it should work.
The config is applied to the tool and on prox out to the current tablet
but then the tool goes in prox on a new tablet and the configuration
doesn't get applied there. In the test we work around this by injecting
an extra proximity event to get the range applied.
This needs some rework in the evdev-tablet code but it's questionable
whether it makes a difference given the small number of users with
multiple tablets and pressure ranges set.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1397>
Previously test devices had to set LITEST_AUTO_ASSIGN to be able
to override an axis-specific value. But this prevented us from
easily overriding other axis values (e.g. tablet tool ids) that usually
have the same value.
LITEST_AUTO_ASSIGN should indicate a value that must always be
auto-assigned, that makes a lot more sense.
This does mean we need to handle ABS_MT_TRACKING_ID -1 to avoid that
getting overwritten by auto_assign_tablet_value() but oh well.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1398>
This only worked because any all our test devices declare a fixed 0
value for x/y in the proximity out event frame. Since 0 !=
LITEST_AUTO_ASSIGN we never got to the litest_scale() for x/y which
would abort because of the -1 value.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1398>
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>
