Previously we restricted rotation to trackballs only and to multiples
of 90 degrees. Update rotation allow angles other than multiples of 90.
Also enable rotation on all mice. The only devices without rotation
are now pointing sticks.
Fixes#827
Signed-off-by: Lucas Zampieri <lzampier@redhat.com>
Check the tag before we read any multiplier quirks. And don't bother
reading the DPI for trackpoints either because it doesn't make sense for
those devices.
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>
A user was experiencing issues with their hand being recognized as
touch input above the stylus tip.
Since touch above the stylus should be rare, increase the touch
arbitration rectangle height by 50mm.
Fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/809
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix the warning generated:
[82/243] Compiling C object libinput.so.10.13.0.p/src_evdev-tablet.c.o
../src/evdev-tablet.c:938:1: warning: unused function
'tool_set_bits_from_libwacom' [-Wunused-function]
tool_set_bits_from_libwacom(const struct tablet_dispatch *tablet,
^
When building with Clang v15 and without libwacom:
$ CC=clang CXX=clang++ meson builddir -Dlibwacom=false
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The escape key can be used to cancel a drag and drop action in some
desktop environments. However, it triggers disable-while-typing, ending
the drag and drop action rather than cancelling it.
Add it to the tp_key_ignore_for_dwt() set to avoid it.
Since I'm here, add the asterisk key as it is the only numpad key not
ignored by tp_key_ignore_for_dwt().
Fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/820 # [1]
Suggested-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Commit 806d4a1393 ("tablet: check libevdev_get_abs_info() return
value") prevented a crash when tilt was deactivated by a quirk.
For more information check [1].
Add similar checks before calling libevdev_get_abs_info() to avoid
possible crashes.
[1] https://gitlab.freedesktop.org/libinput/libinput/-/issues/805
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Commit b5f0536a4f ("quirks: add a quirk for the Wacom 524c device")
added the quirk "AttrEventCodeDisable=ABS_TILT_X;ABS_TILT_Y;" to the
Wacom 524c.
When using the pen in a display with tilt support, the tilt X/Y axes
are set as changed. Using the pen again, but this time in the display
without tilt support, will try to get the tilt information, crashing.
Check the return value of libevdev_get_abs_info() to avoid this crash.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/805
Fixes: b5f0536a4f ("quirks: add a quirk for the Wacom 524c device")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Previously, trackpoints got assigned the normal flat profile which does not
accommodate for the trackpoint magic multiplier *and* had a config range
that was too small if you take the multiplire indo account anyway.
Fix this by adding a trackpoint-specific flat accel that has a wider
configuration range and take sthe magic multiplier into account.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Users that want a flat pointer acceleration want the input speed to
match 1:1 to the output speed, barring a fixed constant multiplier.
This will apply to things like button scrolling as well, so let's map
the constant accel function to the non-constant accel functions to the
speed setting applies to every movement.
This is applied to both the flat and the touchpad flat filter.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The first thing this filter does is normalize the coordinates to
1000dpi, i.e. all other values are in normalized coordinates.
By normalizing the speed again we get an invalid value, effectively
stretching or compressing the acceleration curve. e.g. on a 5000dpi
mouse the estimated speed was 1/5 of the real speed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Our pointer filter code has two functions - one for accelerated movement
and one for "constant" movement (i.e. no accel factor provided but same
conversions). Let's use that instead of a manual normalization.
This fixes an issue with button scrolling on high-dpi mice in the flat
pointer acceleration: normal pointer motion in the flat profile isn't
normalized but the button scrolling was - resulting in e.g. 5 times
slower motion for button scrolling on a 5000dpi mouse.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The filter vs const filter is supposed to be for accelerated vs
non-accelerated motion (e.g. pointer motion vs scrolling) - in both
cases the returned value is supposed to be in the same coordinate
system, just once with an extra accel factor applied.
This was broken in the flat and low-dpi profiles: in both of those the
accelerated filter does *not* normalize, it merely applies the fixed/adaptive factor.
The constant filter normalized however. The result was that on e.g. a
5000dpi mouse the constant motion was 5 times slower than the
accelerated motion, even with a factor of 1.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a leftover from when some of the filter code was shared between
pointer acceleration methods (pre v1.11 or so). Now these functions are
duplicated across files, so both the names and what they do isn't
necessarily reflective anymore.
Let's drop one layer of indirection to make the code a bit easier to
understand.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, this is just for improving readability and a
leftover when some of these functions were used by multiple filters.
This filter normalizes the data first, then applies the acceleration to
the normalized values. So let's keep the data in normalized_coords
structs and only drop to device_float_coords when we have to to use the
tracker API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The IBM/Lenovo Scrollpoint mouse features a trackpoint-like stick that
sends a great amount of scroll deltas.
In order to handle the device, a quirk is in place to normalize the
scroll events as they were relative motion.
However, when high-resolution scroll was implemented, we started
normalizing the hi-res events instead of the lo-res events by mistake.
Fix the quirk by normalizing the right deltas.
Fixes: 6bb02aaf30 ("High-resolution scroll wheel support")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Tested-by: Peter Ganzhorn <peter.ganzhorn@gmail.com>
On mice, switching the acceleration profile to flat disables dpi normalization,
because high or even switchable dpi are generally major features of a
high-end mouse, and switching to flat acceleration indicates that the user
wants to reduce the effects of any cursor acceleration to a minimum.
Therefore we skip normalization there and let the user take full advantage
of their expensive hardware.
On touchpads, particularly those built into a laptop, users have to deal with
whatever hardware they have; touchpad dpi is an afterthought at best, or
a disaster at worst. Switching to the flat profile is more likely to be
about avoiding the non-linear acceleration curve of the adaptive profile.
Hence the flat profile for touchpads shouldn't copy what the one for mice does,
but rather use dpi normalization like the adaptive profile. This keeps flat
acceleration on low-resolution touchpads from dropping to unusably slow speeds.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
Tools default to 1% lower threshold (tip up) and 5% upper threshold (tip
down). But our distance vs pressure exclusion would reset the distance
for *any* pressure value, regardless how low that value was and how high
distance was in comparison.
A very low pressure value of less than 1% would then result in a
normalized pressure of 0, so we'd effectively just reset the distance to
zero and do nothing with the pressure. This can cause distance jumps
when the tool arbitrarily sends low pressure values while hovering as
seen in https://github.com/libsdl-org/SDL/pull/5481#issuecomment-1118969064
Commit 61bdc05fb0 from Dec 2017
"tablet: set the tip-up pressure threshold to 1%"
was presumably to address this but no longer (?) works.
Fix this by addressing multiple issues at the same time:
- anything under that 1% threshold is now considered as zero pressure
and any distance value is kept as-is. Once pressure reaches 1%,
distance is always zero.
- axis normalization is now from 1% to 100% (previously: upper threshold
to 100%). So a tip down event should always have ~4% pressure and we
may get tablet motion events with nonzero pressure before the tip down
event.
From memory, this was always intended anyway since a tip event should
require some significant pressure, maybe too high compared to e.g.
pressure-sensitive painting
- where a tablet has an offset, add the same 1%/5% thresholds, on top of
that offset. And keep adjusting those thresholds as we change the
offset. Assuming that the offset is the absolute minimum a worn-out
pen can reach, this gives us the same behaviour as a new pen. The
calculation here uses a simple approach so the actual range is
slightly larger than 5% but it'll do.
Previously, the lower threshold for an offset pen was the axis minimum
but that can never be reached. So there was probably an undiscovered
bug in there.
And fix a bunch of comments that were either wrong, confusing or
incomplete, e.g. the pressure thresholds were already in device
coordinates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A few lines north of here we return early if neither bit is set. If we
get to this point, at least one bit is set so this part of the condition
always evaluates to true.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This fixes a format string vulnerabilty.
evdev_log_message() composes a format string consisting of a fixed
prefix (including the rendered device name) and the passed-in format
buffer. This format string is then passed with the arguments to the
actual log handler, which usually and eventually ends up being printf.
If the device name contains a printf-style format directive, these ended
up in the format string and thus get interpreted correctly, e.g. for a
device "Foo%sBar" the log message vs printf invocation ends up being:
evdev_log_message(device, "some message %s", "some argument");
printf("event9 - Foo%sBar: some message %s", "some argument");
This can enable an attacker to execute malicious code with the
privileges of the process using libinput.
To exploit this, an attacker needs to be able to create a kernel device
with a malicious name, e.g. through /dev/uinput or a Bluetooth device.
To fix this, convert any potential format directives in the device name
by duplicating percentages.
Pre-rendering the device to avoid the issue altogether would be nicer
but the current log level hooks do not easily allow for this. The device
name is the only user-controlled part of the format string.
A second potential issue is the sysname of the device which is also
sanitized.
This issue was found by Albin Eldstål-Ahrens and Benjamin Svensson from
Assured AB, and independently by Lukas Lamster.
Fixes#752
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All cases we have in our code base have an otherwise unused variable to
loop through the array. Let's auto-declare this as part of the loop.
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>
Declare the variables used to keep track of joystick buttons and
keyboard keys right before they are used for better readability and
consistency.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Create a list of well-known keyboard keys containing one the most
representative key(s) of a group.
The rule is based on the assumption that if the representative key is
present, other keys of the group should be present as well.
The groups are:
- Modifiers group: KEY_LEFTCTRL.
- Character group: KEY_CAPSLOCK.
- Numeric group: KEY_NUMLOCK.
- Editing keys: KEY_INSERT.
- Multimedia keys: KEY_MUTE, KEY_CALC, KEY_FILE, KEY_MAIL,
KEY_PLAYPAUSE and KEY_BRIGHTNESSDOWN.
When 4 of these keys are found, the device is tagged as a keyboard.
Fix#745
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The changes introduced in b5b6f835af to
add support for hold gestures introduced a regression:
The mechanism that was in place to improve the disambiguation between
two finger pinch and scroll during the beginning of the gesture stopped
working and instead a bug warning was printed on the log.
Fix the regression by allowing to go from the scroll state to the pinch
state.
Fix#726
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Since cd4f2f32b5 ("fallback: disable mouse scroll wheel while middle
button is pressed") the mouse wheel is inhibited while the mouse wheel
is pressed.
The original intention of this feature was to avoid unintended scroll
while pressing the scroll wheel. However, now that high-resolution
scroll is fully integrated in libinput we can improve this feature and
filter unintended scroll (below half a detent) and allow it when it is
intended (over half a detent).
Remove the "WHEEL_STATE_PRESSED" state from the wheel state machine and
let the general heuristics handle this case.
Also, remove the specific tests for this feature as now it is covered
by the general test cases.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The device sends its own scroll events when its trackpoint is moved
while the middle button is pressed.
Because scroll events are not going to be inhibited after a certain
amount of scroll is detected in a follow up commit, remove the quirk.
This reverts 53bd70f4c7 ("quirks: Lenovo Trackpoint Keyboard II")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The Wacom 524C device triggers a kernel bug in the InRange and Invert
handling. Every time BTN_TOUCH is set/unset the device also sets/unsets
BTN_TOOL_PEN even when we nominally have the eraser in proximity.
The event sequence effectively looks like this:
# on prox in
BTN_TOOL_RUBBER 1
-- SYN_REPORT ---
# on tip down
BTN_TOOL_PEN 1
BTN_TOUCH 1
-- SYN_REPORT ---
# on tip up
BTN_TOUCH 0
BTN_TOOL_PEN 0
-- SYN_REPORT ---
# on prox out
BTN_TOOL_RUBBER 1
-- SYN_REPORT ---
To work around this, bias our duplicate tool detection code towards the
eraser - if we have an eraser in-prox already and the pen goes
in-prox, ignore it and continue with the eraser. But if we have a pen
in-prox and the eraser goes in-prox as well, force a prox-out for the
pen and put the eraser in-prox.
Recording originally from
https://github.com/linuxwacom/xf86-input-wacom/issues/186Fixes#702
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The changes made in ca3df8a076 to improve
pinch detection introduced a regression:
When the thumb is used to press the clickpad it is automatically tagged
as thumb and the gesture state machine does not initialize it, leaving
its initial X and Y position set to 0.
When another finger is put on the clickpad, the distance moved by the
thumb is checked and because its initial position is 0 movement is
detected.
Add an additional check to take into account only thumbs that are used
in the gesture.
Fix#708
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The most common trigger for this is the debouncing timer which is a mere
12ms and is effectively unavoidable, virtually every caller will
trigger those messages at some point.
Let's add a grace period of 20ms below which we don't log this message
to avoid logspam. And in the process, bump the equivalent warning
message up to 20ms as well.
Related #711
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
