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>
Once we start working with real event frames (i.e. intervals after SYN_REPORT)
we'll always trigger the proximity timeout here. Avoid this by sending one
event with all buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test only succeeded because all events were sent within the dwt timeout.
Change it to actually test the behavior of a touch being disabled by DWT and
staying disabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These only succeeded because the test suite doesn't use frame intervals - as
soon as the time between event frames is nonzero, we may fail these.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We can use the _extended version here. And it turns out the behavior was
slightly different, with the _extended version doing one step too few.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The libinput context's user_data was used for deciding whether to grab the
event device but also to hold the struct window data for the debug-gui. Worked
fine for the initial batch of devices, but any device coming in late would
just use the first field of the struct window to decide whether to grab or
not.
Fixes#122
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already had a check to only pair trackpoints and internal keyboards
but for the ThinkPad Compact Bluetooth Keyboard with TrackPoint that isn't
sufficient - it's an external keyboard that contains a trackpoint. Explicitly
ignore external keyboard, we never want to shut those down in tablet mode
anyway.
Fixes#119
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.
20 min for the "this docker image is ok" marker should be enough but not when
we're hit with random stuck containers in the next stage. By the time those
time out the artefacts have been removed and we now get a dependency error,
forcing us to re-run the whole pipeline.
Since the marker is only a few bytes, we can keep this for a bit longer
without risking running out of space.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a 2-in-1 laptop with detachable keyboard. The AT keyboard
device is used for tablet-integrated keys (volume, leftmeta) and
should not get disabled with tablet-mode enabled.
The touchpad integrated in the detachable keyboard is already
handled through the "Acer Hawaii Keyboard" chicony rule.
Related: https://gitlab.freedesktop.org/libinput/libinput/issues/115
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
* Lenovo MIIX 720 is a tablet with a detachable keyboard. To keep
the volume rockers on the tablet enabled even when the keyboard
is detached, add `ModelTabletModeNoSuspend=1` to the internal
keyboard.
* The external keyboard is a keyboard-touchpad combo. Assign
`AttrTPKComboLayout=below` to the touchpad to allow features
like disable-while-typing and palm-detection.
Looks like this isn't needed, see #112. Or Lenovo re-used USB IDs for this
device in which case we'll have to figure out some other solution once someone
complains.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/112
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, we had a hard threshold of 20mm per event frame. That is just
about achievable by really fast movements (in which case you don't care too
much about the jumps anyway because you've already hit the edge of the screen).
Sometimes pointer jumps have lower deltas that are achievable even on slower,
more likely motions. Analysis of finger motion has shown that while a delta
>7mm per event is possible, jumping _by_ 7mm between two events is unlikely
and indicates a pointer jump. So let's diff the most recent delta and the
current delta, if it increases by 7mm between two event frames let's say it's
a pointer jump and discard it.
Helps with but does not fully resolve:
https://gitlab.freedesktop.org/libinput/libinput/issues/80https://gitlab.freedesktop.org/libinput/libinput/issues/36
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
