GitLab

Hardcoded to 'enabled' right now

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

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

The main purpose of the edge zone is to detect palms in the area where we
cannot assume a full finger size and thus cannot use any other palm detection
mechanism. 8mm should be large enough that a finger should be detected based
on other properties (size, pressure, ...).

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

This patch only adjusted the left edge, not the right edge which was still on
8%

This reverts commit 3e9e0e2e.

The main purpose of the edge zone is to detect palms in the area where we
cannot assume a full finger size and thus cannot use any other palm detection
mechanism. 8mm should be large enough that a finger should be detected based
on other properties (size, pressure, ...).

https://bugs.freedesktop.org/show_bug.cgi?id=103330Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>

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

	if (foo) {
	    everything
	}

changed to :

	if (!foo)
	    return
	everything
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Shove it into the generic dispatch interface so we don't entangle evdev and
fallback.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Better for self-documentation than comments and makes it more obvious if we
initialize something wrongly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

A touchpad that was disabled by toggling the sendevents option would come back
normally after a lid resume, despite still being nominally disabled.

https://bugzilla.redhat.com/show_bug.cgi?id=1448962Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

On some devices with a tablet mode switch, the touchpad is inacessible when
in tablet mode and we don't really need this except to avoid possible ghost
touches (none have been mentioned so far). On other devices like the Lenovo
Yoga, the touchpad points to the back of the device and it's hard to use the
device without accidentally using the touchpad. For those, disabling the
touchpad is the best solution.

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

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

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

Bluetooth wreaks havoc with the timestamp of the input events coming
from the touchpad, enable timestamp smoothing support to counter this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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

There's no guarantee that libinput does the right thing if memory allocation
fails and it's such a niche case on the systems we're targeting that it just
doesn't matter. Simply abort if zalloc ever fails.
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>

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>

So we have something useful to print when we trigger an error in the timer
code.
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>

If the touchpad is suspended and resumed (e.g. lid switch), the initial slot
state may be out of sync. If a touch happened while the touchpad was suspended
and the next touch down is on exactly the same x and/or y coordinate, our
touch point would still have the coordinates of the most recently seen touch
(i.e. before touchpad suspend). This could cause a pointer jump or test case
failures.

The real-world impact of this is minimal, putting the finger down in exactly
the same spot is virtually impossible. It could cause a test case failure in the
lid_disable_touchpad() test though, the second touch sequence was on the same
y coordinate and the touch location for that whole sequence was x/0.
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>

Most modern touchpads are around 100mm wide, so this provides a ca 8mm edge
zone on each side. The extra 3mm should provide for more reliable palm
detection, a few touches happen to be just on the edge of the 5mm mark.

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

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

This is in µs and hasn't been in ms for a long time.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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

We have heuristics for detecting whether a keyboard is internal or external,
but in some cases (e.g. Surface 3) these heuristics fail. Add a udev property
that we can apply to these cases so we have something that's reliable.

This will likely eventually become ID_INPUT_KEYBOARD_INTEGRATION as shipped by
systemd, similar to the touchpad property.

https://bugs.freedesktop.org/show_bug.cgi?id=101101Signed-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>

Sequence triggered by the xorg driver, but basically: if the touchpad is
destroyed before the lid switch, the event listener wasn't removed and an
assertion was triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Instead of reimplementing a for loop every time.
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Reviewed-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>

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>

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

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

Trackpoints are situated so that a user is pretty much guaranteed to trigger
some palm interaction, even if on a small touchpad. Always enable trackpoint
monitoring on touchpads where required.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Nested trinary conditions are fun, but...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>