GitLab

This one only starts with diagonal but continues vertically. Make it clearer.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This test only succeeded because all events were sent within the dwt timeout.
Change it to actually test the behavior of a touch being disabled by DWT and
staying disabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

These only succeeded because the test suite doesn't use frame intervals - as
soon as the time between event frames is nonzero, we may fail these.
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:
#80
#36Signed-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.

#86Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

No touchpad gives us these events with a 0 delay, so let's not test for that.

This is required for adding timing-sensitive scroll code, see
#101.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

A three-finger touch may cause slot N to end, in a frame after the
BTN_TOOL_TRIPLETAP. This causes tp->nfinger_down to be decremented to 2 as the
touch switches to MAYBE_END - which happens to be our num_slots. We exit early
and never restore the touch correctly.

Fix this by checking that the number of fake touches is equal to the slots, if
it is higher then we need to check for recovery.

Fixes #99Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

The tapping code can handle palm states now, so there is no need to disable
tapping altogether when a tool-based palm is detected.

Fixes libinput/libinput#65Signed-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=106498Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

When finger movement exceeded the motion threshold before the finger was
recognized as a thumb, it would never be regarded as a thumb by the tap system.
This prohibited tapping until the thumb was lifted.

This is fixed by moving the check for the thumb state up such that it
happens before the motion threshold check.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

https://bugs.freedesktop.org/show_bug.cgi?id=104188Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

If a touch is in TOUCH_NONE, there is nothing to see here, please move along.

In the case of bug 105696, we were accessing the speed.exceeded_count of a
touch that was released previously, erroneously detecting a speed-based thumb.
The sequence was:
- touch down in slot 0, speed.exceeded_count is reset to 0
- move touch until exceeded_count is greater than our threshold
- touch up in slot 0
- touch down in slot 1 [1]
- touch down in slot 2 (more than 25mm away)
- we counted the slot 0 speed.exceeded_count, labeling the slot 2 touch as
  speed-based thumb

[1] peculiar behavior only observed on this device, usually slots get re-used
at the first opportunity so having an inactive slot followed by higher slots
being used is unusual.

https://bugs.freedesktop.org/show_bug.cgi?id=105696Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This way we can loop through them instead of having to add them manually.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Regression introduced by 3979b9e1, bug 105258.
With that commit, we only ended real touches when we had less than nslots fake
fingers down. i.e. tripletap on a 2 slot touchpad would not end the
first/second touch even if the pressure goes below the threshold. e.g. Lenovo
x270 needs this, see https://bugs.freedesktop.org/attachment.cgi?id=137672, it
dips below the pressure threshold for the first slot and ends the second slot
in the same frame as the third finger is detected. Fun times.

Anyway, this breaks semi-mt touchpads, another fine category of devices,
because some of those can detect hovering fingers at low pressure, see bug
105535. Because semi-mt devices are generally garbage, we treat them as
single-touch devices instead. So whenever two fingers are down, we treat both
as above the pressure threshold, even when they're physicall hovering.

Fix this by making the x270 fix conditional on at least 2 slots.

https://bugs.freedesktop.org/show_bug.cgi?id=105535Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Tiny enough as it is, let's not take usable space away.

https://bugs.freedesktop.org/show_bug.cgi?id=105434Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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=105258Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Only the appletouch has pressure and thus executed that code path
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

On the very first event, the last_motion_time set by tp_begin_touch is not yet
set because we are called before the pressure-based touch detection takes
effect. And any event timestamp is more than 80ms after a zero timestamp,
causing the hysteresis to always be disabled.

https://bugs.freedesktop.org/show_bug.cgi?id=98839#c74Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

8cf6893f removed it to make search/replace easier, restore it for the tests
where we don't want debouncing to automatically be handled.

Still left in place are the various top software button cases. Because of the
button re-routing through the fallback interface we need those to be
debounced.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This is via a simple search & replace. Later auditing is needed to switch
clicks that should not be debounced (e.g. touchpads) back to a non-debounced
version.
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=103156Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Calculate the speed of the touch and compare it against a fixed speed limit.
If a touch exceeds the speed when a second touch is set down, that second
touch is marked as a thumb and ignored (unless it's right next to the other
finger, then it's likely a 2fg scroll).

The speed calculation is simple but has to lag behind by one sample - we reset
the motion history whenever a new finger is set down (to avoid pointer jumps)
so we need to know if the finger was moving fast *before* this happens. Plus,
with the pointer jumps we're more likely to get false positives if we
calculate the speed on actual finger down.

This is the simplest version for now, the speed varies greatly between
movements and should probably be averaged across the last 3-or-so samples.

https://bugs.freedesktop.org/show_bug.cgi?id=99703Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Somehow this ended up being spaces instead of tabs
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Apple touchpads don't use ABS_MT_PRESSURE but they are multitouch touchpads,
so the current pressure-based handling code doesn't apply because it expects
slot-based pressure for mt touchpads.

Apple does however send useful data for ABS_MT_WIDTH_MAJOR/MINOR, so let's use
that instead. The data provided in those is more-or-less random, so we need a
hwdb entry to track the acceptable thresholds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

If the keyboard is removed while dwt thinks it is in active state, that state
is never reset and subsequent touches are ignored.

https://bugs.freedesktop.org/show_bug.cgi?id=101743Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Uninitialized variables, potential NULL dereferences, dead assignments and an
unused return value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This reduces unexpected cursor moves when placing the thumb near the border
of trackpoint buttons and upper edge of touchpad.

https://bugs.freedesktop.org/show_bug.cgi?id=101574Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Without the timeout we're not guaranteed that the tap button event triggers
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Broken since the merge of palm pressure detection in
25d54b90, not sure why the test suite succeeded on that one nonetheless.

I'm not 100% sure why the test does what it does but it seems to be testing
that a wide touch on the side still striggers edge scrolling and not the thumb
detection on the bottom of the touchpad. That is obsolete now, it's hard to
generically figure out the small gap between thumb and palm pressure, so this
test almost always triggers palm detection. It's obsolete.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

If a touch goes past the fixed pressure threshold it is labelled as a palm and
stays a palm. Default value is one that works well here on a T440 and is
virtually impossible to trigger by a normal finger or thumb. A udev property
is exposed so we can handle this in the udev hwdb and the new tool introduce a
few commits ago can help finding the palm detection threshold.

Unlike the other palm detection features, once a palm goes past the threshold
it remains a palm until the touch is released. This means palm overrides any
other palm detection features. For code simplicity, we don't combine the
states but merely check for pressure before and after the other palm detection
functions. If the pressure triggers, it will trigger before anything else. And
if something else is already active (e.g. edge where the pressure doesn't work
well) it will trigger as soon as the palm is released.

The palm threshold should thus be chosen with some room to spare between the
highest finger pressure.

https://bugs.freedesktop.org/show_bug.cgi?id=94236Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This was originally left outside of the button areas in case users tap in
those zones, but we're getting false tap events in that zone.

On a 100mm touchpad, the edge zone is merely 5mm, it's acceptable to ignore
taps in that area even in the software button. We can revisit this if we see
tap detection failures in the future.

https://bugzilla.redhat.com/show_bug.cgi?id=1415796Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

If the touchpad driver tells us something is a palm, go with that.

https://bugs.freedesktop.org/show_bug.cgi?id=100243Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

No effect since we don't care about the mouse itself. But when running
on kernels without uinput's UI_GET_SYSNAME this can cause misdetection of
the uinput device and test case failures. Simply picking a differently named
device avoids that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Introduced in commit 8e7f99c2 we only allowed horizontal edge scrolling
on devices larger than 50mm to leave enough reactive space on the touchpad.
Looking at a ruler, a 50mm high touchpad is still large enough to leave the
bottom 7mm as an horizontal edge scroll area. Reduce the minimum size to 40mm
instead, that's closer to where it starts to get a bit iffy.

https://bugzilla.redhat.com/show_bug.cgi?id=1422221Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>