Some ALPS touchpad send the occasional 4095/0 event on slot 1 during
two-finger interaction before snapping back to the actual position of the
finger. There doesn't seem to be a specific heuristic to predict this so let's
hardcode those values. When detected, overwrite the current touch point with
the position of the last point. This will likely cause a small pointer jump
when the finger later moves to the real position but based on #492 this could
be a second later, so all bets are off anyway.
Fixes https://gitlab.freedesktop.org/libinput/libinput/-/issues/492
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
The previous text wasn't accurate enough, USB used to be considered
external but we've since started deferring to the hwdb for those (except
Apple).
Fixes#483
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
We're getting too many regressions on other devices for this feature and only
ALPS touchpads need it (it's a kernel driver bug). So let's limit this to
those devices only.
For example, synaptics serial touchpads don't keep the fake fingers and slot
states in sync when going from two to three fingers, causing an erroneous slot
downgrade. See
https://gitlab.freedesktop.org/libinput/libinput/issues/434#note_419912
That interferes with this code but fixing it is hard and anyway,
synaptics touchpads don't need the slot count drop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have code in place to handle the quirky transition from two to three
fingers (where one slot ends and another one starts). We do not handle the
same issue when transitioning from three to two fingers.
This is a note only because it hasn't mattered so far, at least until
eb6ef9fe70 from #408. And it doesn't matter anymore now either
because that code is now only called for ALPS devices.
https://gitlab.freedesktop.org/libinput/libinput/issues/434#note_419912
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where fingers are down during startup we need to sync them to the known state
of the device so our slot count is correct. Otherwise, when the fingers are
lifted we will trigger the new assert for nactive_slots being less than 0.
Regression introduced in eb6ef9fe70Fixes#429
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where a user releases all touches during a SYN_DROPPED and then puts more than
one finger back down before we sync, we end up with nonzero fake touches but
a zero slot count. This is caused by a wrong event sequences provided by
libevdev in that case.
This really needs to be fixed in libevdev, see
https://gitlab.freedesktop.org/libevdev/libevdev/merge_requests/19
In the meantime, put a check in to ignore that case and never reduce the slot
count to 0. It still leaves us open for some issues where 3fg gestures may
stop working if the right sequences are triggered during SYN_DROPPED but
updating libevdev will eventually make that go away too.
Fixes#422
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>
__builtin_popcount might not be available on all compilers, so using
it requires a configure check and fallback implementation. In fact
on gcc without an -march flag, it gets compiled to a function call to
libgcc. However, we only need to test whether multiple bits are set,
and this can be done easily with a bitwise and.
Signed-off-by: Michael Forney <mforney@mforney.org>
No real changes for the non-tablet code, but for tablets we now keep the
libwacom datbase around. The primary motivating factor here is response time
during tests - initializing the database under valgrind took longer than the
proximity timeouts and caused random test case failures when a proximity out
was triggered before we even got to process the first event.
This is unfortunately a burden on the runtime now since we keep libwacom
around whenever a tablet is connected. Not much of an impact though, I
suspect, chances are you're running a web browser and everything pales against
that anyway.
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 specify the location that needs to be arbitrated, rather
than just disabling the whole device altogether. This patch just adds the
hooks, no implementation.
This is internal API only, one backend can specify an area in mm which gets
converted to device coordinates in the target device and arbitrated there.
Right now, everything simply passes NULL.
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>
The shape of the average hand implies that two fingers down within the lower
thumb area (the bottom few mm of the touchpad) cannot be thumbs without
significant contortion. So let's not mark them as thumb.
Fixes#126
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tp_detect_thumb_while_moving() assumes that of the 2 fingers down, at least
one must be in TOUCH_UPDATE, otherwise we wouldn't have a speed to analyze for
thumb.
If a touch starts in HOVERING and exceeds the speed limit, we were previously
increasing the 'exceeded count'. This later leads to an assert() in
tp_detect_thumb_while_moving() when the second finger comes down because
although we have multiple fingers, none of them are in TOUCH_UPDATE.
This only happens when fingers 2 and 3 come down in the same event frame,
because then we have nfingers_down at 2 (the hovering one doesn't count) but
we don't yet have a finger in TOUCH_UPDATE.
Fix this twofold, first by now calculating the speed on anything but
TOUCH_UPDATE. And second by force-resetting the speed count on
TOUCH_BEGIN/TOUCH_END so we definitely cover all the hover transitions.
Fixes#150
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Anything that merely requires a once-off check during initialization can just
use the quirks directly, no need to copy them over to the model flags.
Fixes#146
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>
This function expected distances per-frame, not per-time which gives us
different behaviors depending on the hardware scanout rate. Fix this by
normalizing to a 12ms frame rate which reflects the touchpad I measured all
the existing thresholds on.
This is a bit of a problem for the test suite which doesn't use proper
intervals and the change to do so is rather invasive. So for now we set the
interval for test devices to whatever the time delta is so we can test the
jumps without having to worry about intervals.
Fixes#121
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In testing on an Apple Magic Trackpad, thumb touches are reliably
detected by being quite large in the major dimension, but around
half the size in the minor dimension.
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>
libinput applies averaging to the velocity of most pointer devices. Averaging
the velocity makes the motion look smooth and may be of benefit to bad input
devices. For good devices, however, it comes at the unfortunate price of
decreased accuaracy.
This change turns velocity averaging off by default (sets ntrackers to 2 instead
of 16) and allows for it to be turned back on via a quirk, for bad devices which
require it.
