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>
No functional changes, just moving code in preparation for filter patches
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
And switch to a code-flow that's a bit more self-explanatory than the current
min/max combinations.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This makes it more obvious where we're using units/us and units/ms as input
variable and what the output is. Clutters up the code, but still better than
dealing with us/ms differently per function, and still better than carrying
all the 1000.0 multiplications/divisions manually.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
The return value of a profile is a unitless factor, not a speed.
Same applies for s1/s2, these are factors, not speeds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This reverts commit 8a6825f160.
Aside from introducing bugs, this doesn't really help with anything, it adds a
requirement to rename everything to make clear where we're using µs and where
we're using ms and that just clutters up the code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
The previous code used a 5mm threshold before axis events were posted. This
threshold was on top of the 2mm 2fg threshold (and timeout handling) in the
gesture code and effectively prevented events from being sent after a timeout,
or in the 2mm-5mm range.
We still want a directional lock though, so split the two out. The default 5mm
threshold is set to 0 for touchpads since we have our own handling of the
threshold there. The directional lock only applies once scrollin has started
and remains on 5mm.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The new values were in units/us and didn't make the switch back to ms in
8a6825f160.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
If the touchpad is higher than 50mm, enable bottom area thumb detection. This
only applies to the bottom-most 8mm and only if the touch remains unmoving in
that area.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Holding the fingers in place without moving for 500ms is long enough to lock
in a scroll gesture, especially while we're still waiting for the rest of the
stack to expose pinch gestures.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The first finger is accurate, it's just the second finger that is imprecise,
so we can't handle it as a true touch. Instead, revert the device back to
being a single-touch touchpad and use the fake touch bits for second finger
handling.
Two-finger scrolling thus becomes usable though we will lose out on
other features like thumb detection. Useful scrolling trumps that though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Unlike ALPS and Synaptics semi-mt touchpads, the Elantech touchpads appear to
be precise enough to allow a smaller motion threshold before we decide on the
type of gesture (pinch vs scroll).
https://bugs.freedesktop.org/show_bug.cgi?id=91475
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Follow-up to eb146677e, if we disable 2fg scrolling on those touchpads we
should also disable gestures. The data doesn't magically become more useful.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Not all multi-finger touchpads are able to reliably produce gestures, so make
it optional. This patch just adds a boolean (currently always true) that gets
set on touchpad init time, i.e. it is not run-time configurable.
Three and four-finger gestures are filtered out in gesture_notify(), if the
cap isn't set the event is discarded.
For two-finger gestures we prevent a transition to PINCH, so we don't
inadvertently detect a pinch gesture and then not send events. This way, a 2fg
gesture is always scroll.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
There is no need here to use µs since we're just handling speeds/thresholds,
not actual events where a ms granularity can be too high.
Moving back to ms lets us drop a bunch of zeroes that clutter up the code, and
since the acceleration functions are a bit magic anyway, having the various
1000.0 factors in there makes it even less obvious.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
