When pinching, the thumb tends to move slower than the finger, so we may
suppress it too early.
Add a grace period during which it may be revived.
Signed-off-by: novenary <streetwalkermc@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>
This only affects the actual dragging part of the tap-and-drag interaction;
n-finger tap-and-drag is supposed to be performed with a n-finger tap
followed by a 1-finger drag.
Allowing a second finger in the middle of a drag is still necessary for a
finger swap, which users may need in long-distance drags, especially when
drag-lock is disabled.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
This commit duplicates the tap states responsible for tap-and drag (TAPPED
and all DRAGGING* states) to cover two-finger and three-finger taps;
the code for the new states is shared with the existing machinery for
one-finger tap-and-drag.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
This is in preparation for three-finger tap-and-drag, which will start from
a completed tap with no fingers down.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
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>
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>
alps.c hardcodes 5 slots in the kernel but some devices only provide 2 slots
plus BTN_TOOL_TRIPLETAP, etc. Fix this by counting active slots and when the
fake finger count exceeds the active slots but is still less than the number
of slots, adjust the slots themselves downwards.
And because the new test device messes with our slot count assumptions for the
various tests hardcode that one device to return 2 slots.
Fixes#408
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of a simple yes/no/maybe for thumbs, have a more extensive state
machine that keeps track of the thumb. Since we only support one thumb anyway,
the tracking moves to the tp_dispatch struct.
Test case changes:
touchpad_clickfinger_3fg_tool_position:
with better thumb detection we can now handle this properly and expect a
right button (2fg) press for the test case
touchpad_thumb_no_doublethumb_with_timeout:
two thumbs are now always two fingers, so let's switch to axis events here
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, just prep work for a later patch where the thumbs will
dynamically update their state (instead of just using yes/no/maybe).
Extracted from Matt Mayfield's thumb detection patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This moves the thumb state logging directly into that helper function too.
Extracted from Matt Mayfield's thumb detection patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently the same as tp_touch_active() but this will change.
No functional changes.
Extracted from Matt Mayfield's thumb detection patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Follow-up to 6229df184e
We must not rely on the caller to toggle the left-handed bits correctly since
they may not know which devices belong together (despite device groups). Let's
do the right thing here, if the tablet is set to left-handed, rotate the
touchpad accordingly.
Note that the left-handed setting of the tablet is left as-is
(right-handed). Until we have notifications about configuration changes, this
is the best we can do.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tablets in left-handed mode are rotated, so we need to rotate the touchpad
part of them too. This doesn't affect all tablets though, some of them are
symmetrical and the left-handed mode merely changes the button order around
(some of the earlier Bamboos). So we rely on libwacom to tell us which device
must be rotated.
The rotation itself is done on the input coordinate itself as we get it. This
way any software buttons, palm zones, etc. are automatically handled by rest
of the code.
Fixes#274
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This enables us to change the types of touch arbitration, with the focus on
allowing location-based touch arbitration as well as the more generic "disable
everything".
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a 2fg scroll motion starts with both fingers in the bottom button area and
one finger moves into the main area before the other, we used to send motion
events for that finger. Once the second finger moved into the main area the
scroll was detected correctly but by then the cursor may have moved out of the
intended focus area.
We have two transitions where we may start sending motion events: when we move
out of the bottom area and when the finger moves by more than 5mm within the
button area. In both cases, check for any touches that are in the
bottom area and started at the 'same' time as our moving touch. Mark those as
'moved' to release them for gestures so we get the right finger count and
axis/gesture events instead of just motion events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On Dell i2c touchpads, the controller appears to go to sleep after about 1s of
inactivity on the touchpad. The wakeup takes a while so on the next touch, we
may see a pointer jump, specifially on the third event (i.e. touch down,
event, event+jump). The MSC_TIMESTAMP value carries a hint for what's
happening here, the event sequence for a touchpad with scanout intervals
7300µs is:
...
MSC_TIMESTAMP 0
SYN_REPORT
...
MSC_TIMESTAMP 7300
SYN_REPORT +2ms
...
MSC_TIMESTAMP 123456
SYN_REPORT +7ms
...
MSC_TIMESTAMP 123456+7300
SYN_REPORT +8ms
Note how the SYN_REPORT timestamps don't reflect the MSC_TIMESTAMPS.
This patch adds a quirk activate MSC_TIMESTAMP watching. When we do so, we
monitor for a 0 MSC_TIMESTAMP. Let's assume that the first event after that is
the interval, then check the third event. If that third event's timestamp is too
large rewrite the touches' motion history to reflect the correct timestamps,
i.e. instead of the SYN_REPORT timestamps the motion history now uses
"third-event SYN_REPORT timestamps minus MSC_TIMESTAMP values".
The pointer accel filter code uses absolute timestamps (#123) so we have to
restart the pointer acceleration filter when we detect this jump. This allows
us to reset the 0 time for the filter to the previous event's MSC_TIMESTAMP
time, so that our new large delta has the correct time delta too. This
calculates the acceleration correctly for that window.
The result is that the pointer is still delayed by the wake-up window (not
fixable in libinput) but at least it ends up where it should've.
There are a few side-effects: thumb, gesture, and hysteresis all still use the
unmodified SYN_REPORT time. There is a potential for false detection of either
of these now, but we'll have to fix those as they come up.
Fixes#36
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use a boolean for whether we need to use it and drop the unneded absinfo
assignment (together with the goto).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, we had a hard threshold of 20mm per event frame. That is just
about achievable by really fast movements (in which case you don't care too
much about the jumps anyway because you've already hit the edge of the screen).
Sometimes pointer jumps have lower deltas that are achievable even on slower,
more likely motions. Analysis of finger motion has shown that while a delta
>7mm per event is possible, jumping _by_ 7mm between two events is unlikely
and indicates a pointer jump. So let's diff the most recent delta and the
current delta, if it increases by 7mm between two event frames let's say it's
a pointer jump and discard it.
Helps with but does not fully resolve:
https://gitlab.freedesktop.org/libinput/libinput/issues/80https://gitlab.freedesktop.org/libinput/libinput/issues/36
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The software button area is currently a partially-dead area. If the finger
moves into or out of the area pointer motion works. Finger motion within the
area however does not generate motion.
The main motivation for this was to avoid accidental pointer motion when a
button is pressed. This is required for stationary fingers but once you move a
significant distance, those bets are off.
So if the finger moves by more than 5mm from where it was put down, release it
and let it move the pointer.
The full impact is largely limited to horizontal movements within the button
area because:
- leaving the finger at the bottom area for 300ms without movement triggers
the thumb identification, so it won't move anyway.
- moving the finger north is likely to go off the button area before we
trigger this threshold.
https://gitlab.freedesktop.org/libinput/libinput/issues/86
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes two-finger scrolling in straight lines easier, while still
allowing free/diagonal movement. It works in three stages:
1) Initial movement
- For the first few millimeters, scroll movements within 30 degrees
of horizontal or vertical are straightened to 90-degree angles.
- Scroll movements close to 45 degree diagonals are unchanged.
- If movement continues very close to straight horizontal or
vertical, stage 2 begins and the axis lock engages.
- If movement continues along a diagonal, stage 2 is skipped and
free scrolling is immediately enabled.
2) Axis lock
- If the user scrolls fairly closely to straight vertical, no
horizontal movement will happen at all, and vice versa.
- It is possible to switch between straight vertical and straight
horizontal, and the axis lock will automatically change.
- If deliberate diagonal movement is detected at any point, stage
3 begins and the axis lock disengages.
3) Free scrolling
- Scrolling is unconstrained until the fingers are lifted.
This removes the artificial 3 keyboard limit. If you have more internal
keyboards than that, something is wrong in your setup but that shouldn't stop
us from working. Or more specificially: this can happen easily when running
tests so let's not fail the test suite because we created a few hundred
keyboards.
We'll still throw out a log message though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are 4 possible cases why a touchpad suspends right now: lid switch,
tablet mode switch, sendevents disabled and sendevents disabled when an
external mouse is present.
But these reasons can stack up, e.g. a lid switch may happen while send events
is disabled, disabling one should not re-enable the touchpad. This patch adds
a bitmask to remember the reasons we're current suspended, resuming only
happens once all reasons are back to 0.
https://bugs.freedesktop.org/show_bug.cgi?id=106498
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The details are explained in comment in the code. That aside, I shall
mention the check is so light, that it shouldn't influence CPU
performance even a bit, and can blindly be kept always enabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104828
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Prep work for the wobbling detection patch
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
This state is used by the pre-processing of the touch states to indicate that
the touch point has ended and is changed to TOUCH_END as soon as that
pre-processing is finished.
Sometimes we have to resurrect a touch point that has physically or logically
ended but needs to be kept around to keep the BTN_TOOL_* fake finger count
happy. Particularly on Synaptics touchpads, where a BTN_TOOL_TRIPLETAP can
cause a touch point to end (i.e. 1 touch down + TRIPLETAP) but that touch
restarts in the next sequence. We had a quirk for this in place already, but
if we end the touch and then re-instate it with tp_begin_touch(), we may lose
some information about thumb/palm/etc. states that touch already had. As a
result, the state machines can get confused and a touch that was previously
ignored as thumb suddenly isn't one anymore and triggers assertions.
The specific sequence in bug 10528 is:
* touch T1 down
* touch T2 down, detected as speed-based thumb, tap state machine ignores
it
* frame F: TRIPLETAP down, touch T2 up
* frame F+1: touch T2 down in next frame, but without the thumb bit
* frame F+n: touch T2 ends, tap state machine gets confused because
that touch should not trigger a release
https://bugs.freedesktop.org/show_bug.cgi?id=105258
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When drawing on a tablet, the hand usually rests on the device, causing touch
events. The kernel arbitrates for us in most cases, so we get a touch up
and no events while the stylus is in proximity. When lifting the hand off in a
natural position, the hand still touches the device when the pen goes out of
proximity. This is 'immediately' followed by the hand lifting off the device.
When kernel pen/touch arbitration is active, the pen proximity out causes a
touch begin for the hand still on the pad. This is followed by a touch up when
the hand lifts which happens to look exactly like a tap-to-click.
Fix this by delaying the 'arbitration is now off' toggle, causing any touch
that starts immediately after proximity out to be detected as palm and
ignored for its lifetime.
https://bugs.freedesktop.org/show_bug.cgi?id=104985
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, on touch toggle (invoked by the tablet when a pen goes in
proximity) the touchpad cleared the state and ignored any events. Since we
ignore touches that we didn't see the touch begin for, this handled the cases
of a touch remaining after proximity out.
This code pre-dates palm detection, so let's take the bluetack off and instead
integrate it with proper palm detectino.
Previously, touchpad deltas were converted to 1000-dpi normalized coordinates
and handled from there. This changed in bdd4264d61 (1.6)
when the filter functions started taking device coordinates instead. Since
then, we used to convert the device delta to normalized coordinates, then
(often immediately) convert back to device coordinates, albeit for equal x/y
resolution. This isn't necessary, we can just convert the device coordinates
to x/y-equal resolution device coordinates and pass those on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unlike the already-existing thumb detection, a touch may be labelled palm at
any time, not just during the initial touch down. This requires full
integration into the tap state machine to unwind properly. For most states, a
palm detection simply ignores the finger and reverts to the most recent state.
One exception is the case of two fingers down, one finger up followed by the
remaining finger detected as a palm finger. This triggers a single-finger tap
but with timestamps that may be from the wrong finger. Since we're within a
short tap timeout anyway this should not matter too much.
The special state PALM_UP is only handled in one condition (DEAD). Once a
touch is a palm we basically skip over it from then on. If we end up in the
DEAD state after a button press we still need to handle the palm up events
accordingly to be able to return to IDLE. That transition also requires us to
have an accurate count of the real fingers down (palms don't count) so we need
a separate nfingers_down counter for tapping.
https://bugs.freedesktop.org/show_bug.cgi?id=103210
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
needed for the razer blade keybard which provides multiple event nodes for
one physical device but it's hard/impossible to identify which one is the real
event node we care about.
https://bugs.freedesktop.org/show_bug.cgi?id=103156
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Touchpads that require the hysteresis do not have filtering in the firmware
and holding a finger still causes continuous cursor movements. This implies
that we get a continuous stream of events with motion data.
If the finger is on the touchpad but we don't see any motion, the finger is
stationary and the touchpad firmware does filtering. In that case, we don't
need to add a hysteresis on top.
https://bugs.freedesktop.org/show_bug.cgi?id=98839
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
