If the fuzz is 0, assume we don't need hysteresis and use the wobble detection
code instead. If the fuzz is non-zero, enable it by default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We currently used 0.5mm on touchpads as hysteresis value. This causes pointer
movement delays, it is likely too high. Reduce it to a kernel-set fuzz value
(if any) and see how we go with that. On many touchpads, the fuzz is 8 which
would be closer to 0.2mm on e.g. a T440.
Note that the does some defuzzing anyway, but the response of that function is
nonlinear, e.g. for a fuzz of 8, the physical deltas map to:
phys 0..3 → delta 0
phys 4..7 → delta 1
phys 8..15 → delta 4, 5, 6, 7
phys 16..N → delta 16..N
In other words, we never see some logical deltas 2 and 3. While this shouldn't
matter given the average touchpad resolution, reducing the hysteresis margin
is likely to provide some better response. We never see values 8-15 either
which could be the cause of some pointer jumps we've been seeing.
see https://bugs.freedesktop.org/show_bug.cgi?id=105303
Devices with a fuzz of 0 have the hysteresis margin reduced to 0.25mm (from
0.5mm).
https://bugs.freedesktop.org/show_bug.cgi?id=105108
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The hysteresis-returned point always differs from the current point, even if
the hysteresis kicks in. We need to compare to the hysteresis center.
And the returned point is only the new center if we exceed the margin,
otherwise the center stays as-is.
The touch_fuzz() test only succeeded for this because for the values we were
introducing jitter by, the kernel filtered out all the actual movement so
these paths weren't hit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
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>
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>
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>
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>
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>
Similar in style to evemu-play but parses the YAML printed by
libinput-record. Note that this tool requires python-libevdev which is a new
package and may not be packaged by your distribution. Install with pip3 or
alternatively, just ignore libinput-replay, it's a developer tool only anyway.
User-visible differences to evemu-play:
* supports replaying multiple devices at the same time.
* no replaying on a specific device, we can add this if we ever need it
* --verbose prints the event to stdout as we are replaying them. This is
particularly useful on long recordings - once the bug occurs we can ctrl+c
and match up the last few lines with the recordings file. This allows us to
e.g. drop the rest of the file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a tool that does effectively the same job as evemu-record.
evemu has two disadvantages: its API is clunky and hard to extend even for
simple features. And it has a custom file format that requires special
processing but is difficult to extend and hard to write manually. e.g. the
bitmasks require keeping a line number state to know which bit an entry refers
to.
libinput-record records the same data but the output is YAML. That can be
processed easier and extended in the future without breaking the parsing. We
can (in the future) also interleave the evemu output with libinput's debug
output, thus having a single file where the events can be compared and
analysed without the need for replaying. Likewise, we can easily annotate the
file with parsable bits of information without having to shove all that into a
comment (like version numbers of libinput, kernel, etc).
User-visible differences to evemu-record:
* the output file requires an explicit -o or --output-file argument
* no evemu-describe equivalent, if you just want the description simply cancel
before any events are sent
* to see key codes, a --show-keycodes flag must be supplied, otherwise all
'normal' keys end up as KEY_A. This protects against inadvertent information
leakage
* supports a --multiple option to record multiple devices simultaneously. All
recordings have the same time offset, it is thus possible to reproduce bugs
that depend on the interaction of more than one device.
And to answer the question of: why a printf-approach to writing out yaml
instead of a library, it's simply that we want to be able to have real-time
output of the recording.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It's pretty basic as compared to e.g. one of Mesa, but I don't see what
else could be needed, and if anything, it can be added later.
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
When drawing on a tablet, the hand usually rests on the device, causing touch
events. The kernel arbitrates for us in most cases, so we get a touch up
and no events while the stylus is in proximity. When lifting the hand off in a
natural position, the hand still touches the device when the pen goes out of
proximity. This is 'immediately' followed by the hand lifting off the device.
When kernel pen/touch arbitration is active, the pen proximity out causes a
touch begin for the hand still on the pad. This is followed by a touch up when
the hand lifts which happens to look exactly like a tap-to-click.
Fix this by delaying the 'arbitration is now off' toggle, causing any touch
that starts immediately after proximity out to be detected as palm and
ignored for its lifetime.
https://bugs.freedesktop.org/show_bug.cgi?id=104985
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, on touch toggle (invoked by the tablet when a pen goes in
proximity) the touchpad cleared the state and ignored any events. Since we
ignore touches that we didn't see the touch begin for, this handled the cases
of a touch remaining after proximity out.
This code pre-dates palm detection, so let's take the bluetack off and instead
integrate it with proper palm detectino.
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
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>
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>
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>
Some (?) Aiptek tablets have BTN_TOOL_PEN but aren't inclined to actually send
this on proximity in. This means we don't have a tool assigned and ignore the
events.
This patch piggy-backs on the already-existing proximity-out quirks. On the
first EV_SYN and if the tool is still NONE (i.e. no BTN_TOOL_* was received), we
pretend that we've earlier forced a proximity-out event for this tablet. This
causes the proximity-out quirk code to emulate a proximity in and we're off.
Hooray.
https://bugs.freedesktop.org/show_bug.cgi?id=104911
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Mouse and lens cursor tools are rare and the rotation calculation is quirky to
say the least. I don't have access to a non-Wacom mouse tool, so
until this changes, just disable those tools and wait for someone to shout.
This is a much easier fix than trying to figure out the correct generic
rotation calculation that may not be correct anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
