GitLab

For multitap, we're one tap behind with the button clicks, i.e. we send the
first full click button on the second tap, etc. Remember the timestamps of the
touches so we can send the events with the right timestamps. This makes
tapping more accurate because the time between taps and various timeouts
matter less for double-click detection.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

A leftover from synaptics where we do this detection in the driver. libinput
pushes this to the hwdb and sets the model flags accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>

Set the dispatch type on creation, then check that whenever we try to get the
dispatch struct. This avoids a potential mismatch between the backends.

Plus, use of container_of means we're not dependent on the exact layout
anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Don't rely on BTN_TOUCH for "finger down", the value for that is hardcoded in
the kernel and not always suitable. Some devices need a different value to
avoid reacting to accidental touches or hovering fingers.

Implement a basic Schmitt trigger, same as we have in the synaptics driver. We
also take the default values from there but these will likely see some
updates.

A special case is when we have more fingers down than slots. Since we can't
detect the pressure on fake fingers (we only get a bit for 'is down') we
assume that *all* fingers are down with sufficient pressure. It's too much of
a niche case to have this work any other way.

This patch drops the handling of ABS_DISTANCE because it's simply not needed
anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

We need to remember whether a tap was down or just hovering, otherwise we mess
up the state machine when we send tap release events for taps that never
switched to TOUCH_BEGIN. This is quick fix, really we should have a new state
here, but that's a lot harder to implement.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Add listener for lid switch events, disable touchpad on switch event.
Signed-off-by: James Ye <jye836@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Now that the acceleration code doesn't use dpi-normalized coordinates anymore,
we don't need to use them in the touchpad code. Switch to physical distances
instead, it makes debugging a lot saner.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

May help the compiler with further optimization
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Move the code from the touchpad code into the more generic evdev code
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Some trackpoints, notably the one on the Lenovo T460s have a tendency to send
the odd event even when they're not actually used. Trackpoint events trigger
palm detection (see 0210f1fe) and thus effectively disable the touchpad,
causing the touchpad to appear nonresponsive.

Fix this by requiring at least 3 events from a trackpoint before palm
detection is enabled. For normal use it's hard enough to trigger a single
event anyway so this should not affect the normal use-case.

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

So far we've relied on the wacom kernel module to do touch arbitration for us
but that won't be the case in upcoming kernels. Implement touch arbitration in
userspace by pairing the two devices and suspending the touch device whenever
a tool comes into proximity.

In the future more sophisticated arbitration can be done (e.g. only touches
which are close to the pen) but let's burn that bridge when we have to cross
it.

Note that touch arbitration is "device suspend light", i.e. we leave the
device enabled and the fd is active. Tablet interactions are comparatively
short-lived, so closing the fd and asking logind for a new one every time the
pen changes proximity is suboptimal. Instead, we just keep a boolean around
and discard all events while it is set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Inspired by the syndaemon -K switch and Anton Lindqvist's patch.
https://patchwork.freedesktop.org/patch/102417/

We already ignored modifiers for dwt. Now we also ignore modifier + key
combinations, i.e. hitting Ctrl+s to save does not trigger dwt, the touchpad
remains immediately usable.

However, if dwt is already active and a modifier combination is pressed, dwt
remains active, i.e. while typing, a shift + key does not disable dwt.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

All these effectively returned bools anyway, switch the signature over to be
less ambiguous.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>

These are internal functions, if we need them to return an error code we can
change that at any time. Meanwhile, if we only ever return 0 anyway we might
as well just make them voids to save on error paths.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>

Expose the middle button emulation on software buttons as proper config
option. When enabled, remove the middle button software button area.

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

We will reinstate the hysteresis for all devices making the negative
pressure check unncessary.

This reverts commit ef48c07a.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

And change the various callers, especially those where we only had the
separate struct for indentation purposes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Quite a few bugs are caused by touchpad ranges being out of whack. If we get
input events significantly outside the expected range (5% width/height as
error margin) print a warning to the log.

And add a new doc page to explain what is happening and how to fix it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Middle button interaction is most commonly to paste and it is a single-event
interaction (button press). We provided middle button in software button mode
by emulating it with a two-finger press with L+R down at the same time. This
is also what many touchpads are spectacularly bad at, it is very common to
detect the physical button down event before the second finger registers,
resulting in left or right clicks where a middle button should be triggered.

Unless the fingers are resting on the touchpad for at least one scanout, the
success rate for middle button emulation is only at 70% or so.

This patch adds a 25%-width middle button area between the left and the right
software button, everything else stays the same. To avoid immediate breakage,
the middle button emulation remains but may be removed in the future.
The doc is updated to only refer to the middle button area now.

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

Resetting the motion history has the side-effect of swallowing movements, we
don't calculate deltas until we have 4 motion events. During a finger release,
we're likely to get a large pressure change between two events, resetting the
motion history prevents the cursor from jumping on release.

The value of 7 found by trial-and-error, tested on the T440 and T450 hardware.
The absolute value is highly variable but recordings show that the pressure
changes only by 1 or 2 units during normal interaction. Higher pressure
changes are during finger position changes but since those should not cause a
jump anyway, we tend to win there too.

Currently only enabled for negative pressure changes, let's see how we go with
that. This is enabled for all touchpads now, but the value may need
device-specific thresholds in the future.

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

Resetting the motion history has the side-effect of swallowing movements, we
don't calculate deltas until we have 4 motion events. During a finger release,
we're likely to get a large pressure change between two events, resetting the
motion history prevents the cursor from jumping on release.

The value of 7 found by trial-and-error, tested on the T440 and T450 hardware.
The absolute value is highly variable but recordings show that the pressure
changes only by 1 or 2 units during normal interaction. Higher pressure
changes are during finger position changes but since those should not cause a
jump anyway, we tend to win there too.

Currently only enabled for negative pressure changes, let's see how we go with
that.

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

The touchpad's sensors are too far apart (or the firmware interferes), causing
in a jerky movement visible especially on slow motion. We get a bunch of
normal motion events, then only ABS_MT_PRESSURE updates without x/y updates.
After about one mm of movement x/y updates resume, with the first event
covering the distance between the last motion event. That event is usually
accelerated and thus causes a large jump. Subsequent events are sufficiently
fine-grained again.

This patch counts the number of non-motion events. Once we hit 10 in a row, we
mark the first motion update as non-dirty, effectively discarding the motion
and thus stopping the pointer jumps.

https://bugs.freedesktop.org/show_bug.cgi?id=94379Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>

We previously used the half-way mark of the touchpad's y axis to decide where
to ignore tapping. Move this down to the top edge of the software buttons
instead. Users may tap with a finger in the software button areas, on the rest
of the touchpad it's unlikely that they tap within 5% of the edge.

On touchpads with physical buttons or if clickfinger is enabled, the
no-tapping zone extends to the bottom of the touchpad. This required splitting
the tests into clickfinger, softbuttons and hardbuttons.

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

If a key enables dwt and is held down when the timeout expires, re-issue the
timeout.

There is a corner case where dwt may not work as expected:
1. key down and held down
2. dwt timer expires, dwt is re-issued
3. touch starts
4. key is released
5. dwt timer expires
6. touch now starts moving the pointer

This is an effect of the smart touch detection. A touch starting after the
last key press is released for pointer motion once dwt turns off again. This
is what happens in the above case, the dwt timer expiring is the last virtual
key press. This is a corner case and likely hard to trigger by a real user.

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

There are a number of use-cases where tapping may be desirable, but
tap-and-drag is not, e.g. where tapping is used to select multiple items in a
list. Having tap-and-drag on hinders this, and the nature of the interaction
means it cannot be detected based on timeouts, movement thresholds, etc.

Provide an option instead to turn tap-an-drag off. Tap-and-drag remains
enabled by default (though tapping is disabled by default).

For the touchpad tap state diagram, the new option disables the transition
from state TOUCH to state TAPPED and releases the button immediately instead.
This means that multitap-and-drag is disabled too since we now just loop
around in the single-tap state for multitap.

It also makes tapping more responsive - we don't have to wait for the timeout
before we know whether it's a tap event. The first touch time is noted, we now
send the button press with the time of the first touch and the release with
the time of the release. This ensures a realistic time diff between the two
events.

https://bugs.freedesktop.org/show_bug.cgi?id=93502Signed-off-by: Peter Hutterer <peter.hutterer@who-t.netto>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Unused since d92ae62dSigned-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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

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

When adding 3+ finger gestures, there isn't much specific state left that's
2-finger only.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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

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

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>

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=1249365Signed-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>

In most places we use 64 bit unsigned integers; lets be consistent and
use it everywhere.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

If a thumb moves around, it's not resting and we should consider it a normal
touch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

That's the most likely area it will be resting in, if it's sitting anywhere
above that it's likely part of an interaction.

A thumb in the lowest 15mm needs to trigger the pressure threshold before it's
labelled a thumb. A thumb in the lowest 8mm is considered a thumb if it
remains there for 300ms. Regardless of the pressure, since we can't reliably
get pressure here. If a thumb moves out of the area, or starts outside of that
area it is never a thumb.

If edge scrolling is enabled, the 8mm threshold is ineffective since we'll
have normal interaction in that zone for horizontal scrolling.

The thumb tests now require all touchpads to be switched to clickfinger, if we
test for thumb detection on the bottom of the pad we won't get expected
motion events due to the software button area.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

This is not a frequent toggle, so we don't need to jump through too many hoops
here. We simply enable/disable on command and once any current timeouts have
expired the new setting takes effect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>