Pure movement detection is quite unreliable when trying 3-finger pinch
gestures, and many gestures are misdetected as swipes. Before looking at the
motion, look at the constellation of the fingers. If one finger is 20mm below
the other one, assume they're in a pinch position.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Setting TRIPLETAP unsets DOUBLETAP, etc. This doesn't usually happen with
kernel devices, but every once in a while I get this wrong in a test and spend
hours debugging the code...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When three fingers are set down on the touchpad, one finger tends to get a 0/0
coordinate, triggering palm detection in the upper left corner. Handle this
like the jumping semi-mt touchpads and disable MT handling and instead
just rely on the x/y axis and the BTN_TOOL_* events.
https://bugs.freedesktop.org/show_bug.cgi?id=93583
This kernel patch is required:
https://lkml.org/lkml/2016/1/11/171
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A fake MT device may have ABS_MT_POSITION_X but not Y. In this case we don't
care, because we don't handle those axes anyway.
http://bugs.freedesktop.org/show_bug.cgi?id=93474
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Label internal keyboards through the udev hwdb and only pair the internal
(usb) Apple touchpads with those keyboards labelled as such.
https://bugs.freedesktop.org/show_bug.cgi?id=93367
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
open_restricted() doesn't always mean 'open the fd'. When the X server uses
systemd-logind, the fd is opened once before PreInit and then kept open across
devices being disabled and enabled through the protocol.
When the device is re-enabled and libinput_path_add_device is called for the
device, we may have events pending on the fd, leaking information that we
should just ignore.
There's also the potential of inconsistent state. The kernel updates the
device state whenever it processes an event, the evdev ioctls return that
state. If events are pending, the state we see is newer than the events we
process immediately after initialization. That can lead to confusion.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If an x220 is updated to the touchpad firmware version 8.1, the touchpad
suffers from the same issues as the x230 and needs custom acceleration code.
Unfortunately we cannot detect this otherwise, so it is left to the user as a
custom hwdb setting.
https://bugzilla.redhat.com/show_bug.cgi?id=1264453
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Once we trigger diagonal scrolling, the device's scroll direction is set as
horiz+vert. From then on, both axes will be set on every subsequent scroll
event, even when the actual delta for an axis is 0.
This causes continuous scroll stop events in clients that care about these
things.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If all fingers are released in the same frame, we won't be able to find the
top-most touch.
https://bugs.freedesktop.org/show_bug.cgi?id=93204
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These aren't real button events and they are handled elsewhere, either through
proper touch events on touchscreen or through custom handling in the touchpad
case.
https://bugs.freedesktop.org/show_bug.cgi?id=93165
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
At least on the t440, this is enough to trigger correct detection between
pinch and scroll 90% of the time. Since scrolling is significantly more
prevalent than gesturing, erring on the side of scrolling at the cost of
misdetecting some gestures is acceptable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
struct list isn't a null-terminated list, list_for_each() causes 'g' to be set
to the list head at the end of the loop. Returning that as group caused random
memory to be overwritten.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Asus RoG Gladius exposes two event nodes, one mouse, one keyboard. The
keyboard node has REL_X/Y and REL_HWHEEL on top of the various key bits and
ABS_VOLUME.
The keyboard node does not have BTN_* set, udev tags this device as a
keyboard only, not as a pointer but we still initialize the pointer caps for
it because of the wheel.
When moving this mouse, some deltas (ca "1 in every 20") are sent through the
keyboard node, causing a crash because we never initialized pointer
acceleration.
https://bugzilla.redhat.com/show_bug.cgi?id=1275407
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This check is already in place for all other event types.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And use the unaccelerated motion events. Better than crashing, and better than
a non-moving mouse.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
tap-tap-down-move should emit 1 click + press, not 2 clicks + press
https://bugs.freedesktop.org/show_bug.cgi?id=92016
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
If a caller has a reference to a device group when the context is destroyed,
the memory for the group is never released. Calling
libinput_device_group_unref() will release it and there are no side-effects
since the group has no back-references. It's inconsistent with the rest of
libinput though - all other resources get released on libinput_unref().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
The following sequence currently generates a right-button event:
finger 1 down
finger 2 down
finger 1 up
finger 2 held down
This is easily triggered with short scroll events. There are two issues here:
first is that the tapping code elsewhere treats any tap with a second finger
down as a left-button tap, not a right button one. So if anything, we should
generate a left button click here, not a right button click.
Arguably, generating a button click here is wrong though, it's not a very well
defined sequence and relatively difficult to trigger intentionally. So the
best solution here is to simply ignore the release event and move straight
back to state HOLD - unless the second finger is released within the timeout.
If the finger is set down again during the timeout, we move straight to
TOUCH_2_HOLD - this could eventually be interpreted as a tap, but not for now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is both a bug and required behavior. A caller may hold refcounted
references to devices, seats, or device groups but when libinput_unref()
cleans up, all these become invalid.
It is required behavior, because the last call to libinput_unref() also calls
libinput_suspend() and thus stops any events.
Any attempt at fixing this will break current behavior:
* keeping structs until all refcounts are 0 may leak memory in current
callers
* it would require an explicit call to libinput_suspend(), or make
libinput_unref() inconsistent in its behavior.
So we document it as a bug and tell people not to do it.
https://bugs.freedesktop.org/show_bug.cgi?id=91872
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
The x230 has a special acceleration method that relies on the touchpad magic
slowdown. This was missing from commit c8da19b50a, making two-finger
scroll motions unusably fast
https://bugs.freedesktop.org/show_bug.cgi?id=91819
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For short and quick scroll gestures, those that should only trigger a few
lines of scroll the pointer acceleration is wildly unpredictable. Since we
average the motion of both fingers it's hard enough to intuitively predict
what the motion will be like. On top of that is the small threshold before we
start scrolling, so some of the initial motion gets swallowed before we
accelerate, making the next motion even more unpredictable.
The end result is that multiple seemingly identical finger motions cause
wildly different scroll motion.
Drop pointer acceleration for two-finger and edge scrolling. This makes short
scroll motions much more predictable and doesn't seem to have much effect on
long scroll motions. Plus, in natural scroll mode it really feels like the
content is stuck to your fingers now. Go wash your hands.
https://bugzilla.redhat.com/show_bug.cgi?id=1249365
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For when we need to apply some transformation to the data but it shouldn't be
acceleration. Example use are touchpad coordinates, even when not
accelerating, we still want to apply the magic slowdown.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Requires splitting out the X230 one so we don't accidentally break things if
we ever change this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Don't open-code the rate-limited log messages, use a simple wrapper instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A device with REL_X/Y and keys gets marked only as ID_INPUT_KEY, initializes
as keyboard and then segfaults when we send x/y coordinates - pointer
acceleration never initializes.
Ignore the events and log a bug instead. This intentionally only papers over
the underlying issue, let's wait for a real device to trigger this and then
look at the correct solution.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is step one to fixing trackpoint acceleration, separating it from the
other acceleration code. No functional changes yet, it still uses the low-dpi
accel method.
https://bugs.freedesktop.org/show_bug.cgi?id=91369
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This is "once-tested, don't touch it again" code. The quirks on the touchpad
means we'd have to find that specific device again and re-test everything if
we change anything elsewhere in the code. So duplicate it properly, so that we
don't have to touch it again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Instead of going straight to pointer_notify_axis, go through
evdev_notify_axis() which flips the scroll direction around for us.
https://bugs.freedesktop.org/show_bug.cgi?id=91597
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous approach to pointer acceleration was to initialize the same
motion filter behavior but a different acceleration profile depending on the
hardware (the profile converts a speed to a multiplier for input deltas).
To be more flexible for hardware-specifics, change this into a set of specific
pointer acceleration init functions. This patch has no effective functional
changes, they're still all the same.
The acceleration functions are kept for direct access by the ptraccel-debug
tool.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
