We're left-shifting the bits but weren't comparing against the l_r_l mask
itself. So if we get a sequence of [1, 1, 0, 1] we didn't detect a wobble
because 0b1101 != 0b101 (what we're looking for).
Fix this by turning it into a right shift, that way the bits fall off
the mask automatic
al
ly
y
y
y
y
. .
_._v.___
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 5883ac7d98)
Otherwise a hovering touch stays around forever even after the finger has
discontinued. This doesn't matter on slots, but for fake fingers the finger
may suddenly end up being forced down/up as a result of the pressure changes
on the real fingers.
So when in maybe_end_touch, switch them back to NONE immediately - hovering
touches do not need to trigger a TOUCH_END event.
https://bugs.freedesktop.org/show_bug.cgi?id=105258
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d8db6b5927)
This changes the hysteresis region to an ellipse (usually a circle), where
previously it was a rectangle (usually square).
Using an ellipse means the algorithm is no longer more sensitive in some
directions than others. It is now omnidirectional, which solves a few
problems:
* Moving a finger in small circles now creates circles, not squares.
* Moving a finger in a curve no longer snaps the cursor to vertical
or horizontal lines. The cursor now follows a similar curve to the
finger.
https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=105306
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 6936a15558)
This state is used by the pre-processing of the touch states to indicate that
the touch point has ended and is changed to TOUCH_END as soon as that
pre-processing is finished.
Sometimes we have to resurrect a touch point that has physically or logically
ended but needs to be kept around to keep the BTN_TOOL_* fake finger count
happy. Particularly on Synaptics touchpads, where a BTN_TOOL_TRIPLETAP can
cause a touch point to end (i.e. 1 touch down + TRIPLETAP) but that touch
restarts in the next sequence. We had a quirk for this in place already, but
if we end the touch and then re-instate it with tp_begin_touch(), we may lose
some information about thumb/palm/etc. states that touch already had. As a
result, the state machines can get confused and a touch that was previously
ignored as thumb suddenly isn't one anymore and triggers assertions.
The specific sequence in bug 10528 is:
* touch T1 down
* touch T2 down, detected as speed-based thumb, tap state machine ignores
it
* frame F: TRIPLETAP down, touch T2 up
* frame F+1: touch T2 down in next frame, but without the thumb bit
* frame F+n: touch T2 ends, tap state machine gets confused because
that touch should not trigger a release
https://bugs.freedesktop.org/show_bug.cgi?id=105258
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 6ccd8e934f)
If we have more BTN_TOOL_*TAP fingers down than we have slots, ignore any
below-threshold pressure changes on the slots. When a touchpad only detects
two touches, guessing whether the third touch has sufficient pressure is
unreliable. Instead, always assume that all touches have sufficient pressure
when we exceed the slot number.
Exception: if all real fingers are below the pressure threshold, the fake
fingers are ignored too.
Related to https://bugs.freedesktop.org/show_bug.cgi?id=105258
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 3979b9e16a)
Only the appletouch has pressure and thus executed that code path
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 21b83dfd0b)
This test worked because on devices that don't use pressure the touches were
reset when BTN_TOUCH when to 0, triggering the 'ignore fake fingers when no
real fingers are down' behavior. But this is a different code path than the
pressure handling, so let's separate those tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 990da54aa6)
The details are explained in comment in the code. That aside, I shall
mention the check is so light, that it shouldn't influence CPU
performance even a bit, and can blindly be kept always enabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104828
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
(cherry picked from commit 400aadd53a)
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
(cherry picked from commit e8dffbd73a)
Prep work for the wobbling detection patch
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
(cherry picked from commit e43bd4ae3a)
The sd-bus interface we're using wasn't public until 221.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 8353eeb5a8)
Missing '+' in the optstring caused it to evaluate all options. If any
argument was passed to a subcommand, libinput-measure would throw an error and
exit.
https://bugs.freedesktop.org/show_bug.cgi?id=105246
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 59550ed21c)
If a single-touch touchpad drops below the pressure threshold in the same
frame where a fake finger is added, we begin a fake touch here. The subsequent
loop ends this fake touch because real_fingers_down is 0.
This causes the tapping code to have a mismatch of how many fingers are down
because it never sees the touch begin event for that finger.
https://bugs.freedesktop.org/show_bug.cgi?id=105160
(cherry picked from commit 01a633b6eb)
Tweak this python scripts to use '/usr/bin/env python3'
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 920debffd7)
If libdir is an absolute path (which means it’s outside of prefix) we
would wrongly add the prefix to it in the install script. Just pass the
correct libdir from Meson directly thanks to join_paths() magic.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit b2b5cdaf61)
Since the install script cannot know the correct bindir, just pass it
from Meson directly.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 0843fa8e5e)
A set of wireless devices that can scramble the timestamps, so we get
press/release within 8ms even though I doubt the user is capable of doing
this. Since they're generally good quality anyway, let's just disable
debouncing on those until someone complains and we need something more
sophisticated.
https://bugs.freedesktop.org/show_bug.cgi?id=104415
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 3a3fd645c4)
Rotation on a tool can either ABS_Z or in the case of the mouse/lens tools a
combination of ABS_TILT_X/Y. The code assumes that if the rotation on a stylus
(not mouse/lense) changes, we need to fetch it from ABS_Z. This happens on the
very first event from the tablet, proximity in invalidates all axes so we can
send the current state to the caller.
On libwacom-recognized tablets we never set the rotation bit on the stylus, so
that's all fine. On tablets without libwacom support, the stylus may have a
rotation bit copied because we have it set thanks to mouse+tilt on the tablet.
When that first event is handled, we try to access ABS_Z. On tablets without
ABS_Z like Aipteks, we go boom.
Fix this by checking for ABS_Z during tablet init, if we don't have that axis
then never set the rotation bit on the tool. That's the only axis where we
need this, all other axes have a single cause only and thus the tablet bits
are accurate anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=104939
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looks like a libinput bug (well, it does say "libinput bug" on the
package) but it hasn't been that for a long time. The cause is almost always
insufficient motivation to call libinput_dispatch() by the caller, or at least
not doing it with the celerity libinput demands (and deserves, if I may say
so).
Up-, down- or side-grade it to a client bug, so the outrage can be
directed elsewhere, preferably away from me. And add a section to the
documentation, just in case someone actually reads this stuff.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
So we don't have to have newline handling in the callers. This effectively
reverts 6ab2999be9 "test: detect linebreaks in log messages".
https://bugs.freedesktop.org/show_bug.cgi?id=104957
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If there's anything that listens for KEY_POWER it will likely shut down or
suspend the host. Since it doesn't matter whether we're really testing for
KEY_POWER or just any other key, let's just switch it and avoid one headache.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having the system suspend or shutdown halfway through a test run is a tad
annoying. So let's talk to logind and tell it to inhibit the various keys
we're testing.
https://bugs.freedesktop.org/show_bug.cgi?id=104720
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This broke with meson 0.44 and results in an error:
RuntimeError: Could not determine how to run Meson. Please file a bug with details.
See https://github.com/mesonbuild/meson/issues/2761
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, touchpad deltas were converted to 1000-dpi normalized coordinates
and handled from there. This changed in bdd4264d61 (1.6)
when the filter functions started taking device coordinates instead. Since
then, we used to convert the device delta to normalized coordinates, then
(often immediately) convert back to device coordinates, albeit for equal x/y
resolution. This isn't necessary, we can just convert the device coordinates
to x/y-equal resolution device coordinates and pass those on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On the very first event, the last_motion_time set by tp_begin_touch is not yet
set because we are called before the pressure-based touch detection takes
effect. And any event timestamp is more than 80ms after a zero timestamp,
causing the hysteresis to always be disabled.
https://bugs.freedesktop.org/show_bug.cgi?id=98839#c74
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When running the test suite in full fork mode, the error messages are in the
quite verbose output and searching for them is annoying. Work around this by
opening a pipe to each subprocess and writing the failed test cases to that
pipe. When all tests have finished, print the messages to stdout. This way the
failures are always the last thing printed by the test suite.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Some pens keep sending small amounts of pressure even when the tip is up. This
isn't always a sign of the pens worn out, it also happens on the new Pro Pen
3D models.
The X driver uses a default threshould of ~1.3% to paper over this, let's do
the same with a 1% threshold. This threshold only applies to pens that don't
already have a pressure offset anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=103086
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
