The EVDEV_UDEV_TAG_JOYSTICK is set when a joystick or gamepad button
is found. However, it can not be used to identify joysticks or
gamepads because there are keyboards that also have it. Even worse,
many joysticks also map KEY_* and thus are tagged as keyboards.
In order to be able to detect joysticks and gamepads and
differentiate them from keyboards, apply the following rules:
1. The device is tagged as joystick but not as tablet
2. It has at least 2 joystick buttons
3. It doesn't have 10 keyboard keys
Fix#701Fix#415Fix#703
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Move the logic to detect joysticks and gamepads to its own function.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Adds touchpad pressure configuration for Lenovo Yoga 2 Pro in order to avoid random cursor jumps on finger up.
Signed-off-by: Joaquin Gonzalez <joaquin.gonzalez.uy@gmail.com>
Add two helper functions that set/unset BTN_TOUCH together with the
specified axes and switch all tests over.
Devices can override the tip down/up sequence.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a clickpad announcing BTN_RIGHT in different machines, see
issue #674, #689, #629 and MR !701. There are at least 4 machines that
ship with this device that we had to quirk independently, possibly
others so disabling BTN_RIGHT on all of them makes sense.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Follow the name convention used in evdev-wheel.c and rename the handle
event functions from "tp_gesture_[STATE]_handle_event" to
"tp_gesture_handle_event_on_state_[STATE]".
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Most mice with high-resolution support have a mechanism in place to
adjust the wheel to a detent. When scrolling, it is possible to stop
between two detents and this mechanism could generate a small amount of
scroll in the oposite direction.
Track the scroll direction in the wheel state machine and reset it when
the direction changes to avoid this issue.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Mice with high-resolution support can generate deltas when the finger is
put on the wheel or when the user tries to click the wheel.
To avoid sending involuntary scroll events, add an extra state the the
wheel state machine to accumulate scroll deltas.
While the accumulated scroll is lower than a certain threshold, ignore
them until the threshold is reached.
Since no finish event is sent by the mouse, reset the state machine
after a period of scroll inactivity.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
In order to be able to add more complex rules in the future, transform
the current wheel handling code into a state machine.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Before hold gestures where implemented, when a thumb was detected it
was enough to reset the state machine.
However, now it is possible to detect a thumb while a hold gesture is
in course.
Cancel any ongoing gesture when a thumb is detected to avoid dropping
the gesture end event.
See #693
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This patch contains a new button invoked scrolling mode optimized for
use with 5 button mice. The preferred invokation button is the thumb
button, BTN_SIDE in evdev parlance. The initial direction of motion of
the mouse following press of the invoking button sets the scroll axis
and the sign of the subsequent scroll reports. Once set the axis and sign
of the scroll reports can only be changed by releasing and re-pressing
the invocation button. This scheme allows for arbitrarily long scroll
distances without lifting and replacing the mouse.
Only one axis is active for scrolling at a time. The preferred scroll
motion is circular, but any type of mouse motion is acceptable. The
distance scrolled is proportional to the manhattan distance moved by the
mouse. The dynamic range is expanded non-linearly based on movement
velocity such that the +-2^8 input range of mouse motion reports is
expanded to a +-2^16 range of scroll reports. The scheme takes maximum
advantage of the precision of the mouse, both arbitrarily slow and quite
fast scrolling are accommodated. The performance of the mode is such that
the scroll thumb is only needed for reference, it need never be "touched".
The mode is optimized for y axis use. The y axis is preferred in that axis
determination happens more easily for the y axis than for the x axis. This
is accomplished by creating a wider movement cone for y axis selection
than for x axis selection. Also, x axis selection can only begin following
a delay, now 250ms, from button press, whereas y axis selection is
immediate with as little dead/wasted movement as possible. The reason
for this asymmetry is personal. I find that when I am reflexively using
the mode I may move the mouse more to the left than I am intending,
particularly while I am simultaneously pressing the button and starting
motion. This behavior can result in x axis selection when y axis is
intended. Since I almost never scroll the x axis, I solved the problem
by heavily preferring the y axis. The more deliberate criteria for
selecting the x axis do not bother me at all. Of course I could have
defeated x axis selection entirely, but after significant use of the mode
I find the current setup to be almost foolproof for the y axis while
still allowing x selection without using up another button.
The mode is optimized for the internet browsing use case, following
hyperlinks and scrolling the resulting pages. Care is taken to assure
that the user is not confused by overloading the scroll modal button
with any other action. Once the new mode is assigned to a button,
that button cannot be used for any other purpose. Therefore, those that
are used to using mouse buttons 4 and 5 for their historical design use,
browsing forward and backward, may not initially take to the new mode.
However, patience might be rewarded sooner than one would think. At least
for some, the new mode easily becomes intuitive and automatic. And since
scrolling is performed far more frequently on modern systems than browsing
forward and backward, the increased efficiency of entering the scrolling
mode more than pays for the loss of button browsing behavior.
I've not before submitted code to the libinput project. Therefore I have
limited the changes to a single source file, evdev.c. Also, I have
conditioned the submitted changes so that the new mode is only operational
on devices that have the udev environment variable LIBINPUT_SIGNED_SCROLL
defined with a value of "1". An example udev rule to add such an
environment variable to a Microsoft 5-Button Mouse with IntelliEye follows:
ACTION=="add|change", KERNEL=="event[0-9]*", ENV{ID_VENDOR_ID}=="045e", \
ENV{ID_MODEL_ID}=="0039", ENV{LIBINPUT_SIGNED_SCROLL}="1"
I don't really know how to go about getting this change incorporated into
the libinput project. I've attempted to make the change in such a way as
to not interfere with any existing functionality. Further, I've made the
new functionality available only via the above not easily discoverable
incantation. In this way I'm hoping to get the change incorporated into
the main project so that others can somewhat easily try out the new mode.
Once people are comfortable that the new mode doesn't break anything, the
next step would be to make it more publicly usable via changes further
libinput changes plus changes to xorg-xf86-input-libinput and/or the
similar? wayland input driver.
Signed-off-by: Paul Ausbeck <paula@alumni.cse.ucsc.edu>
Don't use the litest wrapper context here, it changes log priority if
the test suite is run with --verbose, causing the test to fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
During the transition from GESTURE_STATE_HOLD_AND_MOTION to
GESTURE_STATE_POINTER_MOTION the last pointer motion event was
processed twice.
Fix#680
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Some devices might announce support for high-resolution scroll wheel
by enabling REL_WHEEL_HI_RES and/or REL_HWHEEL_HI_RES but never send
a high-resolution scroll event.
When the first low-resolution scroll event is received without any
previous high-resolution event, print a kernel bug warning and start
emulating high-resolution scroll events.
Fix#668
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Later versions of this same model seem to have a different ALPS touchpad
and don't need the pressure settings. Narrow down this match so we only
apply to the one from the actual bug report in #565.
Fixes#676
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
LIBINPUT_EVENT_GESTURE_HOLD_BEGIN and LIBINPUT_EVENT_GESTURE_HOLD_END
were missing from libinput_event_gesture_get_base_event.
Add them to avoid triggering an erroneous client bug warning.
Fix#671
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
When required, invert horizontal scrolling in evdev_notify_axis_wheel
following the QUIRK_MODEL_INVERT_HORIZONTAL_SCROLLING quirk.
Fix#669
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
External touchpads using USB are vanishingly few, built-in touchpads
that use USB are comparatively common. So let's default to internal,
for vendors like Logitech and Wacom that only make external touchpads we
have special conditions in place anyway.
Fixes#664
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When pairing a trackpoint, use the model flags for the touchpad, don't
use a separate set of conditions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
GTK handles LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS as
GDK_SCROLL_SMOOTH, the same event type that is used to handle
LIBINPUT_EVENT_POINTER_SCROLL_FINGER.
Because Mutter and other compositors, like wlroots based compositors,
translate libinput terminating event to axis_stop instead of doing their
own emulation, if libinput stops sending terminating events, it will
cause client bugs.
Since libinput always sends the terminating event for trackpoints and
button scrolling and there are even tests in place to check for them,
update the documentation to guarantee the terminating scroll sequence.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
It's been a while since we really could do something about those jumps,
so let's assume most of these are informative and not a bug in libinput.
For that let's not spam the user's journal and ratelimit it to a handful
a day.
Per day because that increases the chance of an error being present in
the recent logs if the user does search for it.
Related #663
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touchpad is removed before its dwt-paired keyboard, we're leaking
the keyboard struct. Fix this by cleaning up properly when our device is
removed.
This is the cause of many failed tests in the udev backend tests during
the CI valgrind run. Because we're testing the udev backend it will add
any devices created by tests run in parallel, some of which are keyboard
devices. Depening on the test completions, the keyboards may or may not
get removed before this device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the kernel doesn't support a touchpad, the device is handled as a
generic mouse named "ImPS/2 Generic Wheel Mouse".
Taps are handled as button clicks and the button debouncing code makes
it difficult to double click.
Add a quirk to disable button debouncing for this devices.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/656
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Move the logic used to parse boolean quirks and udev flags to a common
function in utils.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
