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>
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>
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>
If --compress-motion-events is given (and stdout is a tty) reduce
the output printed to one line per repeated motion/axis/scroll sequence
(with a count). Example output:
event6 POINTER_MOTION 108 +1.912s 1.00/ -1.00 ( +1.00/ -1.00))
event6 POINTER_BUTTON +2.008s BTN_LEFT (272) pressed, seat count: 1
event6 POINTER_BUTTON +2.074s BTN_LEFT (272) released, seat count: 0
event6 POINTER_MOTION 39 +5.249s 0.00/ 0.99 ( +0.00/ +1.00)
event6 POINTER_BUTTON +5.385s BTN_LEFT (272) pressed, seat count: 1
event6 POINTER_MOTION 66 +6.031s -1.00/ 0.00 ( -1.00/ +0.00)
event6 POINTER_BUTTON +6.401s BTN_LEFT (272) released, seat count: 0
The event count (108, 39 and 66) is only printed for more than one event
in sequence so the output is otherwise identical (but 4 spaces wider
now)
If stdout is not a tty the event count is printed but no compression
happens since we rely on a ansi escape sequence for that. Could be fixed
by changing the current print statements to print a \n before the
current event instead of at the end of the current line.
This makes debugging events easier as button events and similar are no
longer obscured by pages of motion events in between.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1041>
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add option to control whether the touchpad should be disabled while the
trackpoint is in use.
Fix#731
Signed-off-by: pudiva chip líquida <pudiva@skylittlesystem.org>
The messages with priority DEBUG refer to the various internal state machines
updating, so it's useful to know when they did so. Let's count up every time
we trigger libinput_dispatch() so we know how the messages group together.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This shuts up scan-build complaining about memory leaks in libinput
debug-events (needs the right combination of --device option and eventually
triggering usage()) and saves us a bunch of unnecessary allocations.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scroll button locking is an accessibility feature. When enabled, the scroll
button does not need to be held down, the first click holds it logically down,
to be released on the second click of that same button.
This is implemented as simple event filter, so we still get the same behavior
from the emulated logical button, i.e. a physical double click results in a
single logical click of that button provided no scrolling was triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All configuration options will only apply to the device with the given match
mattern. This makes it easier to test things like tapping on one device but
not on the other.
Exception is the sendevents pattern which applies independently.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We want to use this from the tests as well soon, so let's move it to a more
generic location. This also changes the API to be slightly more sensible, a
free() is the same cost (and safer) than passing a static buffer in and hoping
we didn't get the size wrong.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the most common use-case other than "all from udev", so let's just
parse a device path correctly without requiring --device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only one place really needs the return argument, so we might as well just pass
the memory to be returned in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When running libinput tools from the builddir, look up the subtools in the
builddir as well. Otherwise, add the install prefix to the list of lookup
locations.
This ensures that a) we're running builddir stuff against builddir stuff, but
also b) that we're not running builddir stuff against installed stuff because
that may give us false positives.
The test was squashed in from a separate patch and was
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This way we can re-use this from libinput-record instead of having to
duplicate all this. Since the two tools use different printfs, just make the
actual printing a simple callback.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The &grab pointer we used to pass as userdata was the address of the function
argument which goes out of scope at the end of the function. This works fine
for devices immediately opened but when a device connects later, the address
may have been re-used since and it's content is undefined. If not NULL, we
end up grabbing the device.
Instead pass the grab option in which is guaranteed to live until the end of
main.
https://gitlab.freedesktop.org/libinput/libinput/issues/26
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looked good on paper but clearly no-one (including myself) ever tested this
in a real-life situation or they would've noticed that the constant factor is
missing, causing a segfault on the first two-finger scroll event, touchpad
gesture or button scrolling.
Adding the constant factor makes the API much worse and the benefit is
unclear, so out of the window it goes. We can revisit this for libinput 1.12
but this isn't going to make the next release.
This reverts commit d8bd650540.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This adds a third profile to the available profiles to map device-specific
speed to an acceleration factor, fully defined by the caller.
There has been a consistent call for different acceleration profiles in
libinput, but very little specifics in what actually needs to be changed.
"faster horses" and whatnot (some notable exceptions in e.g. bug 101139).
Attempts to change the actual acceleration function will likely break things
for others.
This approach opens up the profile itself to a user-specific acceleration
curve. A caller can set an acceleration curve by defining a number of points
on that curve to map input speed to an output factor. That factor is applied
to the input delta.
libinput does relatively little besides mapping the deltas to the
device-specific speed, querying the curve for that speed and applying that
factor. The curve is device-specific, the input speed is in device units/ms.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We had one shared parsing function for all config options so tools parse
options that don't actually make sense (e.g. --quiet or --show-keycodes for
libinput-list-devices).
This patch splits the actual libinput device configuration out and reshuffles
everything to make use of that. One large patch, because splitting this up is
more confusing than dumping it all.
This means the actual option parsing is partially duplicated between debug-gui
and debug-events but hey, not everything in life is perfect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the first tool of many more to come to enable users to gather
information aobut their devices and/or usage of these devices. Previously,
these required the users to record events, submit them to a bugzilla, have me
run various scripts over it and then decree that the scripts have spoken.
Push some of this into the hands of the users so they can query the numbers
locally and start investigating (or at least get an idea of what's happening).
This tool measures the time deltas between touch up and touch down and prints
a basic summary, together with the ability to print a dat file with the data
for visualization by e.g. gnuplot. Eventually, more of the current analysis
scripts will be moved into this or other helpers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the debug-gui is a user-visible tool, make sure the usage reflects
the right command name.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Chaining args together inside a single binary would be nice, but it gets nasty
quickly (as I found out adding 3, 4 extra commands). Switch over to using a
git-style exec-ing command where libinput merely changes argv[0] and then
executes whatever it assembled. And those binaries can hide in libexec so they
don't clutter up the global namespace.
This also makes it a lot easier to write man pages, adopt the same style as
git uses.
Compatibilty wrapper scripts are provided for libinput-list-devices and
libinput-debug events. These warn the user about the changed command, then
exec the new one. Expect these wrappers to be removed at some point in the
future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Supresses any printf statements from the tool itself, i.e. it skips printing
any of the events.
Makes it easier to debug the internal state since it's not intermixed with a
whole lot of messages about the events that are generated. Best combined with
--verbose (yes, hilarious, isn't it...)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
libinput-debug-events prints keycodes as they come in. This makes it dangerous
to be run by users (especially in the background) because it will leak
sensitive information as it is typed. Obfuscate the base set of keycodes
by default, require a --show-keycodes switch to show it.
The few times we actually need the keycodes, we can run the switch in the
debugging tool.
This does not affect keys outside of the main block on the keyboard (F-keys,
multimedia keys).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
../tools/shared.h:66:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
void tools_usage();
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previously hardcoded button map for tapping is 1/2/3 to LRM. But the
middle button is a common feature on the desktop (used for paste, most
prominently) and three-finger tapping is almost impossible to do reliably on
some touchpads (e.g. the T440 has a recognition rate of ~1 in 5).
Left and right buttons have a prominent physical position (either softbuttons
or physical buttons) so make the tap order configurable. Those that require
middle buttons reliably can use the [software] buttons for left/right and
2-finger tap for a middle button.
https://bugs.freedesktop.org/show_bug.cgi?id=96962
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
There are a number of use-cases where tapping may be desirable, but
tap-and-drag is not, e.g. where tapping is used to select multiple items in a
list. Having tap-and-drag on hinders this, and the nature of the interaction
means it cannot be detected based on timeouts, movement thresholds, etc.
Provide an option instead to turn tap-an-drag off. Tap-and-drag remains
enabled by default (though tapping is disabled by default).
For the touchpad tap state diagram, the new option disables the transition
from state TOUCH to state TAPPED and releases the button immediately instead.
This means that multitap-and-drag is disabled too since we now just loop
around in the single-tap state for multitap.
It also makes tapping more responsive - we don't have to wait for the timeout
before we know whether it's a tap event. The first touch time is noted, we now
send the button press with the time of the first touch and the release with
the time of the release. This ensures a realistic time diff between the two
events.
https://bugs.freedesktop.org/show_bug.cgi?id=93502
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.netto>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The quartett of new config functions is:
libinput_device_config_accel_get_profiles
libinput_device_config_accel_get_profile
libinput_device_config_accel_set_profile
libinput_device_config_accel_get_default_profile
The profile defines how the pointer acceleration works, from a very high-level
perspective. Two profiles are on offer, "adaptive", the standard one we have
used so far and "flat" which is a simple multiplier of input deltas and
provides 1:1 mapping of device movement vs pointer movement.
The speed setting is on top of the profile, a speed of 0 (default) is the
equivalent to "no pointer acceleration". This is popular among gamers and
users of switchable-dpi mice.
The flat profile unnormalizes the deltas, i.e. you get what the device does
and any device below 800dpi will feel excruciatingly slow. The speed range
[-1, 1] maps into 0-200% of the speed. At 200%, a delta of 1 is translated
into a 2 pixel movement, anything higher makes it rather pointless.
The flat profile is currently available for all pointer devices but touchpads.
https://bugs.freedesktop.org/show_bug.cgi?id=89485
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
DWT can interfere with some applications where keyboard and touchpad use at
the same time is common, e.g. games but also anything that requires a
combination of frequent pointer motion and use of keyboard shortcuts.
Expose a toggle to disable DWT where needed.
https://bugs.freedesktop.org/show_bug.cgi?id=90624
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Issues an EVIOCGRAB on the openend devices, providing exclusive access. Makes
it easier for debugging, so moving the pointer doesn't accidentally trigger
other stuff.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We need the options during open_restricted(), so instead of the caller just
passing in a custom userdata, let them wrap it into a tools_context.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
