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>
When we disable the touch device, any existing touches should be cancelled,
not just released.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This touchpad stops sending pressure data after the first frame of the second
finger down. If the initial pressure is too light, the finger doesn't get
detected even when the pressure increases in the future.
This thing is from 2014, so let's just disable the pressure axes on it
and skip the pressure-based touch detection code. Let's hope that it doesn't
also have ghost touches on light interactions...
Fixes#145
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>
Fix libinput_event_destroy call by passing the correct parameter (event) in the
example code.
Signed-off-by: Diego Rondini <diego.rondini@kynetics.com>
The hwdb match entry used to be this one:
libinput:name:*Elan Touchpad*:dt:*
LIBINPUT_ATTR_PRESSURE_RANGE=10:8
from commit 596777a314. It was intended to match
for devicetree only but the way the udev rules were composed, it ended up
matching on any system.
Restore that for all systems to have compatibility with 1.11. For this one,
let's also add the resolution hint and hope that that works too.
Fixes#140
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Was 0x800 in the hwdb, became 0x8000 in th quirks transition because of
inflation, but let's pretend the economy is back to normal and devalue our
currency. (aka: "it was a typo", whoops and whatnot)
https://bugs.freedesktop.org/show_bug.cgi?id=104415
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous check only worked if sizeof(long) > sizeof(int). Rather than be
fancy about it, just cast to a signed long, check for negativity and continue
based on that.
Fixes#137
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All we do now is to set the fuzz, so we only ever need to care about this when
a device has absolute axes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was removed accidentally as part of a9ef4ba1f3 and then completely dropped in
870ddce9e4 when the hwdb was deprecated completely. The model quirks call
is also the one that reads and sets the LIBINPUT_FUZZ property, effectively
making that code a noop.
Fixes#138
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We may get a pointer jump on tip down/up, see #128. For absolute coordinates
we reset the history to avoid smoothing across that jump but deltas still used
to be calculated based on the previous position to the current one. This
can result in a large jump on tip down.
Since the delta is supposed to be useful (and not physically accurate, see the
docs), let's force it to 0/0 on tip down/up to avoid that scenario.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because we're doing axis smoothing, we may get a nonzero delta between events
even when the real axis hasn't updated. Make sure the bit is set in this case.
One part of #128
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Bit of a weird diff, print_tablet_axes() was moved up and a single call to
print_tablet_axes() was added in the tablet tip event handler.
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>
This is mostly taken from the Weston Contributing.md document.
Main changes from there are:
- more detailed step-by-step on how to create a MR
- commit history/messages in two sections
- s/Weston/libinput/
I skipped the Review/Commit Rights sections for now until there's some demand
for it. Same with the Licensing/Stabilising for releases sections.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
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>
We never want to accidentally trigger this one. Where we trigger them on
purpose, we can swap the log handler out first.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This forces events for every ~10ms now. If we want a slower movement, we need
more steps - just like a real touchpad does it.
Cocinelle spatch files were variants of:
@@
expression A, B, C, D, E, F, G, H, I, J, K;
@@
- litest_touch_move_two_touches(A, B, C, D, E, F, G, H, I)
+ litest_touch_move_two_touches(A, B, C, D, E, F, G, H)
The only test that needed a real fix was touchpad_no_palm_detect_2fg_scroll,
it used 12ms before, now it's using 10ms so on the bcm5974 touchpad the second
finger was a speed-thumb. Increasing the events and thus slowing down the
pointer means it's a normal finger and the test succeeds again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Change a number of tests to use 10ms intervals between finger events and fix
the coordinates up accordingly to avoid pointer jumps. This is in preparation
for a test-suite wide use of 10ms intervals.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
move_to() now uses delays, let's make this test more robust for timing errors
so we don't fall below the threshold movement we want to trigger.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The coordinates ended up being in the first touch detected as palm. Not
relevant for this test, but let's not do that to avoid false positives.
Also change to 10ms intervals, more realistic given the hardware.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
