This was never true, we for the first part 3 lines above and return early. So
if we get here, it's always false.
commit aa87d2b25b added the new condition above, so since then this code
was inactive and can be removed.
https://bugs.freedesktop.org/show_bug.cgi?id=104279
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>
This has no real effect at the moment because the fallback interface doesn't
care much about SYN_REPORT, it processes events as they come in. But it's a
bug nonetheless, the process() callback expects correct event frames.
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>
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=103330
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=103330
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
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=1448962
Signed-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=102408
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=99703
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>
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>
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=101743
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=101574
Signed-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=94236
Signed-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=101433
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=101101
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=1415796
Signed-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>
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>
