"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>
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>
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>
I'd be surprised if those get removed before the whole X11 support is
removed - and in that case we can remove the x11 support as well.
So let's disable the warnings and deal with it when it truly breaks -
there are no replacements for what we want to do here after all.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1233>
Color touches above the minimum threshold and above the down threshold
so it's easier to analyze a recording. Sometimes touches move
unexpectedly but if it's low-enough pressure this may not affect
libinput.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1225>
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>
Two advantages here: fewer actual printf() calls making the output
slightly more coherent if there are other things writing to stdout but
also better re-usability since we can now move the print functions to
shared code.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1156>
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>