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>
There appears to be a race condition where an ABS_MT_TRACKING_ID -1
event is on the wire but libevdev_fetch_slot_value() for that slot
already gives us -1 as well.
If we just (re)opened our device, synching our slots would thus set zero
active slots and then trigger the assert when that event is being
processed.
It's unclear how to reliably reproduce this issue but removing the
assert and simply ignoring this event if we don't have active slots
is correct anyway.
Closes#1050
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1081>
Confusingly, tp_gesture_handle_state() would do almost nothing with our
state machine and the various tp_gesture_handle_state_foo() were called
later from tp_gesture_post_gesture().
Rename those functions into so that we have
tp_gesture_update_finger_state() first followed by
tp_gesture_handle_state() which is responsible for dealing with the
state machine.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1049>
We ignore modifiers for disable-while-typing because we don't want to
disable the touchpad for things like shift-click or ctrl-click.
We also do remember the modifier state so that we don't disable the
touchpad for once-offs like ctrl+s.
Shift is however a special case - shift + something else is means the
user is typing and we should disable the touchpad for that.
Closes#1005
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1015>
Where a more generic match assigns a palm threshold to a device, allow
unsetting this by assigning a threshold of zero.
And remove the bug log for palm size threshold of 0 for the same reason.
The range is (max - min + 1) because the kernel range is inclusive min
and max. Let's fix that once and for all with a helper function.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This hurts more than it helps, and users complain of dead trackpad
edges. Apple touchpads have fairly sophisticated internal palm rejection
algorithms going back many years, so let's just disable this one on
everything Apple.
Related to: #433 (need to figure out what other hardware may need this)
Signed-off-by: Hector Martin <marcan@marcan.st>
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>
Unlike in traditional touchpads, whose pressure value equals contact
size, on pressure pads pressure is a real physical axis.
We don't take advantage of the pressure information reported by
pressure pads yet, so we disable it to avoid errors.
Add a new model quirk for pressure pads instead of disabling
ABS_MT_PRESSURE and ABS_PRESSURE.
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>
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>
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>
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 1 or 2 fingers are used to hold, use a faster timer to make the
"hold to stop kinetic scrolling" user interaction feel more immediate.
Also handle double tap and tap and drag interations to send only one
hold gesture instead of two.
Holding with 3 or 4 fingers remains the same to try to avoid callers
missusing hold gestures to build their own tap implementation.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Hold gestures are notifications about fingers on the touchpad.
There is no coordinate attached to a hold gesture, merely the number of fingers.
A hold gesture starts when the user places a finger on the touchpad and
ends when all fingers are lifted. It is cancelled when the finger(s) move
past applicable thresholds and trigger some other interaction like pointer
movement or scrolling.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
At the moment, every gesture is triggered by motion. In order to implement
gestures not based on motion, like hold, it is required to filter the unwanted
motion inside the gesture state machine so it transits to the correct states.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Use a bool instead of an int and also rename the variable to avoid ambiguity
with tp_filter_motion().
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The way touchpads (generally) work is that they get the position of each
finger on each scanout. The kernel filters touches that haven't moved to
reduce bandwidth so any touch that is logically down that we don't see an
update for is in the same position as during the last scanout.
Previously, touches that didn't sent events were effectively ignored, causing
our jump detection to fail:
- time t0: touch moves to position x/y, motion history time is set to t0
- time t1..t5: touch remains at position for several frames, no updates to the
motion history
- time t6: touch jumps to position x+a/y+b
- tp_detect_jumps() sees the last update time is t0 which is too long ago
and exits without detecting a jump
This is fixed by pushing to the motion history any time we have *any* update -
if the touchpad notices a state change on any touch update all touches with
their current position, whether it changed or not.
This obsoletes the `time` field in the tp_touch struct, most of this patch is
passing down the current time to the few users of t->time.
Fixes#578
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The kernel/udev set the pressure resolution to nonzero to indicate the value
is in a known scale (units/g). We use that information to disable the
pressure axis on such devices - real pressure cannot be translated to
contact size.
For the kernel patch see:
https://www.spinics.net/lists/linux-input/msg71237.htmlFixes#569
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On serial touchpads it's common enough that frames slow down tofrom the usual
12ms to 24ms. That's too close to our 25ms cutoff so if we have a minor delay,
we end up missing out on jump detection.
Fixes#541
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some ALPS touchpad send the occasional 4095/0 event on slot 1 during
two-finger interaction before snapping back to the actual position of the
finger. There doesn't seem to be a specific heuristic to predict this so let's
hardcode those values. When detected, overwrite the current touch point with
the position of the last point. This will likely cause a small pointer jump
when the finger later moves to the real position but based on #492 this could
be a second later, so all bets are off anyway.
Fixes https://gitlab.freedesktop.org/libinput/libinput/-/issues/492
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This touchpad has firmware that seems to buffer events. In the words of the
reporter:
In usage, it feels like motions vary between smooth and choppy; slow
movements are smooth and quick movements are choppy. It's as if the
touchpad aggregates quick movements and sends one big movement instead
of sending discrete events. To make the movement more natural, the
events preceding the jump should be of higher magnitude and the jump
less pronounced, but that's just not how the touchpad works, it seems.
In the actual event data this looks exactly like a pointer jump: small
movements, one big one, then small ones again. If we filter that large
movement out we prevent the user from moving quickly.
There's no way to detect this or work around this, so let's add a quirk that
disables the jump detection for this device.
Fixes#506
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
!292 improved libinput's ability to detect multiple-finger clicks when
the fingers were not aligned close to horizontally. However that caused
thumb detection to fail in several use cases.
This patch restores thumb detection for
- 2+ finger physical clickpad presses
- resting thumb while two-finger scrolling
- touches in the thumb exclusion area during multi-finger taps
and improves pinch detection when thumb is centered below fingers.
It also further enhances the flexibility of finger position for 2-, 3-,
or 4-finger taps: if all tapping fingers land on the touchpad within a
short time (currently 100ms), they will all count regardless of
position (unless below the lower_thumb_line).
Signed-off-by: Matt Mayfield <mdmayfield@yahoo.com>
The previous text wasn't accurate enough, USB used to be considered
external but we've since started deferring to the hwdb for those (except
Apple).
Fixes#483
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In most cases these days touch jumps aren't actually fixable, they don't have
any good heuristics we can employ to remove them. And, luckily, in most cases
it doesn't matter because the users only notice the issue because of the error
message. To avoid spamming the user's log, let's ratelimit it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're getting too many regressions on other devices for this feature and only
ALPS touchpads need it (it's a kernel driver bug). So let's limit this to
those devices only.
For example, synaptics serial touchpads don't keep the fake fingers and slot
states in sync when going from two to three fingers, causing an erroneous slot
downgrade. See
https://gitlab.freedesktop.org/libinput/libinput/issues/434#note_419912
That interferes with this code but fixing it is hard and anyway,
synaptics touchpads don't need the slot count drop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have code in place to handle the quirky transition from two to three
fingers (where one slot ends and another one starts). We do not handle the
same issue when transitioning from three to two fingers.
This is a note only because it hasn't mattered so far, at least until
eb6ef9fe70 from #408. And it doesn't matter anymore now either
because that code is now only called for ALPS devices.
https://gitlab.freedesktop.org/libinput/libinput/issues/434#note_419912
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
