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>
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>
delta_time can be zero when:
- the fallback acceleration function is used for multiple movement types
(for example, pointer motion and wheel scrolling simultaneously)
- two different methods produce the same movement at the same time
(for example, button-scrolling and wheel-scrolling)
Reusing the last delta_time is a graceful fallback even if there are
duplicate events or event-ordering bugs.
Signed-off-by: Yinon Burgansky <yinonburgansky@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1336>
Dispatch high-resolution scroll wheel events through filter_dispatch_scroll
so they can be accelerated using the custom acceleration profile.
Low-resolution scroll wheel events are not accelerated to avoid zero
delta-time in the filter.
Signed-off-by: Yinon Burgansky <yinonburgansky@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1316>
A few changes to the Lua API didn't get reflected in the example
plugins, let's update them.
Also included here is naming of all arguments, instead of _ use the
argument name even where unused. These are examples so being expressive
is more important than making any lua static checkers happy.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1339>
"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>
Python 3.14 has changed from fork to forkserver[1] which causes
libinput replay to fail with the following error when starting the
subprocesses:
ValueError: ctypes objects containing pointers cannot be pickled
This is caused by the libevdev device being passed to the sub process.
A more proper fix may be to only initialize the device in the subprocess
and then signal the process to start replaying. But meanwhile, switching
back to fork will do.
[1] https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methodsCloses#1204
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1330>
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>
These devices had the debouncing disabled via a model quirk but
really they are virtual devices and should have all hw-specific
processing disabled - on the assumption that this will be handled
in the host. See also e.g. commit 5d23794d53 ("tablet: disable
smoothing for uinput devices").
Closes#1175
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1308>
HP OmniBook Ultra Flip Laptop 14-fh0xxx manages itself keyboard and
touchpad deactivation when HP's custom Intel ISH firmware is installed
in the system. Without the custom firmware tablet-mode switch isn't
exposed so there is no way we don't need this.
More detailed information in the file comment.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1311>
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>
