"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>
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>
Slightly less efficient but easier to read and it's not possible to
accidentally provide the wrong length. Plus it handles null pointers
correctly so get to skip the checks (which weren't needed for strneq()
either, but still).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1121>
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>
Adds a dedicated scroll movement type to the custom acceleration profile.
Supported by physical mouse and touchpad.
Other profiles remain the same by using the same unaccelerated filter for the scroll filter.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
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>
This switches the quirk from AttrEventCodeEnable/Disable to just
AttrEventCode with a +/- prefix for each entry.
This switches the quirk from AttrInputPropEnable/Disable to just
AttrInputProp with a +/- prefix for each entry.
Previously, both event codes and input props would only apply the
last-matching section entry for a device. Furthermore, an earlier Disable entry
would take precedence over a later Enable entry. For example, a set of
sections with these lines *should* enable left, right and middle:
[first]
AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT;BTN_MIDDLE
[second]
AttrEventCodeDisable=BTN_RIGHT
[third]
AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT;
Alas: the first line was effectively ignored (quirks only returned the
last-matching one, i.e. the one from "third"). And due to implementation
details in evdev.c, the Disable attribute was processed after Enable,
i.e. the device was enabled for left + right and then disabled for
right. As a result, the device only had BTN_LEFT enabled.
Fix this by changing the attribute to carry both enable/disable
information and merging the commands together.
Internally, all quirks matching a device are simply ref'd into an array
in the struct quirks. The applied value is simply the last entry in the
array corresponding to our quirk.
For AttrEventCode and AttrInputProp instead do this:
- switch them to a tuple with the code as first entry and a boolean
enable/disable as second entry
- if the struct quirk already has an entry for either, append the more
recent one to the existing entry (instead of creating a new entry in
the array). This way we have all entries that match and in-order of
precedence - i.e. we can process them left-to-right to end up
with the right state.
Fixes: https://gitlab.freedesktop.org/libinput/libinput/-/issues/821
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>
When a boolean quirk was displayed its real value was ignored and
instead a hardcoded value of 1 was always used.
Get the quirk real value and display it.
Fix#725
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/512 disables
input smoothing for AES devices. However, some AES devices produce
segmented/wobbly curves without smoothing. This change introduces an
`AttrTabletSmoothing` boolean property, which overrides the default smoothing
behavior.
See #632
Signed-off-by: Quytelda Kahja <quytelda@tamalin.org>
Alternate between two randomly-chosen colors for each batch of debug messages
to make it easier to visually group the two.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Given that some people appear to not read until the "is not installed" part of
the error message, let's reduce the error message to just that part. This may
be confusing where a user mistypes the actual command but that happens rarely
compared to those that can't run libinput record because it's in a different
package.
Fixes#500
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When a boolean quirk is set to "0", it is correctly disabled, but "libinput quirks list" and
"libinput record" showed it as "1".
This happens for example if ModelXXXX=0 is set in /etc/libinput/local-overrides.quirks, to
override a default quirk.
Signed-off-by: Loïc Yhuel <loic.yhuel@softathome.com>
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>
Positive side-effect - this exposed a bunch of missing #includes that got
pulled in by other headers before.
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>
