There's no need for a custom error message everywhere, it's better to log the
current state and the event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Do so on the synaptics serial touchpads at least, they're known to cause
cursor jumps when the third finger is down. Not detecting a tap move means
three-finger taps get more reliable on these touchpads.
This change affects gestures who now effectively have to wait for the tap
timeout to happen. It's a trade-off.
https://bugs.freedesktop.org/show_bug.cgi?id=101435https://bugzilla.redhat.com/show_bug.cgi?id=1455443
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes the tapping times shorter and hopefully more obvious. It also fixes
a bug where repeated tripletap (by tapping with one finger while leaving the
other two down) could cause incorrect timestamps.
https://bugs.freedesktop.org/show_bug.cgi?id=100796
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For multitap, we're one tap behind with the button clicks, i.e. we send the
first full click button on the second tap, etc. Remember the timestamps of the
touches so we can send the events with the right timestamps. This makes
tapping more accurate because the time between taps and various timeouts
matter less for double-click detection.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Prefix device log messages with the device's sysname so it's more obvious
where the messages are coming from. This makes it much easier to grep for a
specific device's messages but also adds some identifier to messages that
were previously without any identifier (e.g. all the state machine debugging)
All info and error messages also automatically prefix the device name, so
those messages are standardised too, e.g
an info message now:
event4 - SynPS/2 Synaptics TouchPad: is tagged by udev as: Touchpad
a debug message now:
event4 - using pressure-based touch detection
And since this required changing a lot of the strings in messages anyway,
polish a few minor things too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Set the dispatch type on creation, then check that whenever we try to get the
dispatch struct. This avoids a potential mismatch between the backends.
Plus, use of container_of means we're not dependent on the exact layout
anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We need to remember whether a tap was down or just hovering, otherwise we mess
up the state machine when we send tap release events for taps that never
switched to TOUCH_BEGIN. This is quick fix, really we should have a new state
here, but that's a lot harder to implement.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the acceleration code doesn't use dpi-normalized coordinates anymore,
we don't need to use them in the touchpad code. Switch to physical distances
instead, it makes debugging a lot saner.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
When a finger moves less than the movement threshold, motion is filtered until
the timeout is hit. If the threshold is too high the responsiveness of the
pointer suffers.
Event analysis from several users showed that 95% of the touches move less
than 1.3mm long. Reducing the threshold should have almost no impact on most
tapping users but improves the reaction time of the pointer for normal
movements.
For a more details see:
http://who-t.blogspot.com/2016/12/libinput-touchpad-tap-analysis.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is the timeout before we decide "this is just a finger down, not a tap".
Until this timeout is hit a finger's movement is filtered. To allow for a more
responsive touchpad, we want that timeout as short as possible.
Event analysis from several users showed that 95% of the touches are less than
100ms long. Reducing the threshold should have almost no impact on most
tapping users but improves the reaction time of the pointer for normal
movements.
For a more details see:
http://who-t.blogspot.com/2016/12/libinput-touchpad-tap-analysis.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We have one. Yay. Lucky us. Go forth and celebrate.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
The previously hardcoded button map for tapping is 1/2/3 to LRM. But the
middle button is a common feature on the desktop (used for paste, most
prominently) and three-finger tapping is almost impossible to do reliably on
some touchpads (e.g. the T440 has a recognition rate of ~1 in 5).
Left and right buttons have a prominent physical position (either softbuttons
or physical buttons) so make the tap order configurable. Those that require
middle buttons reliably can use the [software] buttons for left/right and
2-finger tap for a middle button.
https://bugs.freedesktop.org/show_bug.cgi?id=96962
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These are internal functions, if we need them to return an error code we can
change that at any time. Meanwhile, if we only ever return 0 anyway we might
as well just make them voids to save on error paths.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
There are a number of use-cases where tapping may be desirable, but
tap-and-drag is not, e.g. where tapping is used to select multiple items in a
list. Having tap-and-drag on hinders this, and the nature of the interaction
means it cannot be detected based on timeouts, movement thresholds, etc.
Provide an option instead to turn tap-an-drag off. Tap-and-drag remains
enabled by default (though tapping is disabled by default).
For the touchpad tap state diagram, the new option disables the transition
from state TOUCH to state TAPPED and releases the button immediately instead.
This means that multitap-and-drag is disabled too since we now just loop
around in the single-tap state for multitap.
It also makes tapping more responsive - we don't have to wait for the timeout
before we know whether it's a tap event. The first touch time is noted, we now
send the button press with the time of the first touch and the release with
the time of the release. This ensures a realistic time diff between the two
events.
https://bugs.freedesktop.org/show_bug.cgi?id=93502
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.netto>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
tap-tap-down-move should emit 1 click + press, not 2 clicks + press
https://bugs.freedesktop.org/show_bug.cgi?id=92016
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The following sequence currently generates a right-button event:
finger 1 down
finger 2 down
finger 1 up
finger 2 held down
This is easily triggered with short scroll events. There are two issues here:
first is that the tapping code elsewhere treats any tap with a second finger
down as a left-button tap, not a right button one. So if anything, we should
generate a left button click here, not a right button click.
Arguably, generating a button click here is wrong though, it's not a very well
defined sequence and relatively difficult to trigger intentionally. So the
best solution here is to simply ignore the release event and move straight
back to state HOLD - unless the second finger is released within the timeout.
If the finger is set down again during the timeout, we move straight to
TOUCH_2_HOLD - this could eventually be interpreted as a tap, but not for now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
In order to provide higher precision event time stamps, change the
internal time measuring from milliseconds to microseconds.
Microseconds are chosen because it is the most fine grained time stamp
we can get from evdev.
The API is extended with high precision getters whenever the given
information is available.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
That's the most likely area it will be resting in, if it's sitting anywhere
above that it's likely part of an interaction.
A thumb in the lowest 15mm needs to trigger the pressure threshold before it's
labelled a thumb. A thumb in the lowest 8mm is considered a thumb if it
remains there for 300ms. Regardless of the pressure, since we can't reliably
get pressure here. If a thumb moves out of the area, or starts outside of that
area it is never a thumb.
If edge scrolling is enabled, the 8mm threshold is ineffective since we'll
have normal interaction in that zone for horizontal scrolling.
The thumb tests now require all touchpads to be switched to clickfinger, if we
test for thumb detection on the bottom of the pad we won't get expected
motion events due to the software button area.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Most thumbs are detected a few events into the sequence. Work this into parts
of the tapping state machine. Only the most common use-case is handled here -
if the first finger ends up being marked as a thumb, we return to the idle
state and ignore that touch sequence.
At any other state, we handle thumbs like any other finger.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
All touchpad recordings seen so far show that a value above 100 is definitely
a thumb or a palm. Values below are harder to discern, and the same isn't true
for touchpads supporting ABS_PRESSURE instead of ABS_MT_PRESSURE.
The handling of a touch is as outlined in tp_thumb_detect:
* thumbs are ignored for pointer motion
* thumbs cancel gestures
* thumbs are ignored for clickfinger count
* edge scrolling doesn't care either way
* software buttons don't care either way
* tap: only if thumb on begin
The handling of thumbs while tapping is the simplest approach only, more to
come in follow-up patches.
Note that "thumb" is the synonym for "this touch is too big to be a
fingertip". Which means that a light thumb touch will still be counted as a
finger. The side-effect here is that thumbs resting a the bottom edge of the
touchpad will almost certainly not trigger the pressure threshold because
most of the thumb is off the touchpad.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Similar to tapping, it's a feature that is useful but confusing if a user
doesn't know it exists. It makes the touchpad appear laggy and slow to react
in the best case, or appear like a stuck button in the worst case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
In some applications, notably Inkscape, where it is common to frequently drag
objects a short distance the default to drag-lock always-on is frustrating for
users.
Make it configurable, with the current default to "on".
New API:
libinput_device_config_tap_set_drag_lock_enabled
libinput_device_config_tap_get_drag_lock_enabled
libinput_device_config_tap_get_default_drag_lock_enabled
Any device capable of tapping is capable of drag lock, there is no explicit
availability check for drag lock. Configuration is independent, drag lock may
be enabled when tapping is disabled.
In the tests, enable/disable drag-lock explicitly where the tests depend
on it.
https://bugs.freedesktop.org/show_bug.cgi?id=90928
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
To quote Bryce Harrington from [1]:
"MIT has released software under several slightly different licenses,
including the old 'X11 License' or 'MIT License'. Some code under this
license was in fact included in X.org's Xserver in the past. However,
X.org now prefers the MIT Expat License as the standard (which,
confusingly, is also referred to as the 'MIT License'). See
http://cgit.freedesktop.org/xorg/xserver/tree/COPYING
When Wayland started, it was Kristian Høgsberg's intent to license it
compatibly with X.org. "I wanted Wayland to be usable (license-wise)
whereever X was usable." But, the text of the older X11 License was
taken for Wayland, rather than X11's current standard. This patch
corrects this by swapping in the intended text."
libinput is a fork of weston and thus inherited the original license intent
and the license boilerplate itself.
See this thread on wayland-devel here for a discussion:
http://lists.freedesktop.org/archives/wayland-devel/2015-May/022301.html
[1] http://lists.freedesktop.org/archives/wayland-devel/2015-June/022552.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
The current 500ms is too long, reduce it to 300ms instead. This is still long
enough to get multiple movements but not that long that it feels like the
button is stuck.
https://bugs.freedesktop.org/show_bug.cgi?id=90613
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Currently for the tap-and-drag gesture to end user has to wait for a
timeout to expire. Make it possible to end the drag gesture by just tapping.
The allowed finger sequences to start and end a drag are thus:
tap, down, .... move ...., up <wait for timeout>
tap, down, .... move ...., up, tap
https://bugs.freedesktop.org/show_bug.cgi?id=90255
Signed-off-by: Velimir Lisec <lisec.velimir@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
State diagram changes and a doc change squashed in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use tp->nfingers_down as trigger when we have no fingers left on the touchpad
and when we should return to idle. If all touchpoints end in the same frame
tp->nfingers is 0. Thus when we handle the first tap release we transition to
IDLE which now needs to handle (and discard) any touch release events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
libinput supports lifting a finger during dragging and setting it back down
again to continue the drag. Curently the drag timeout is set to
DEFAULT_TAP_TIMEOUT. That is to short, when we're dragging the finger needs to
have enough time to move from one edge of the touchpad to the other. 180ms is
too short for that and causes false timeouts and thus button releases that
cancel the drag.
Introduce DEFAULT_DRAG_TIMEOUT and set it to 500 ms.
Signed-off-by: Velimir Lisec <lisec.velimir@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The current doubletap timeout was incorrect, it gave the user only 180ms to
touch, release, touch, release to recognise a doubletap. But it would also set
a timeout on the second release, delaying the button events by 180ms.
Instead, re-arm the timer on the second touch down. This gives the user 180ms
to release and touch again (or time out). This makes doubletap much more
reliable and reduces the delay between the release and the button events
arriving since the finger down time is already counted.
Same fix for MULTITAP, though we already armed the timer on touch down so we
just have to remove the new timer on touch release which did little but delay
everything.
https://bugs.freedesktop.org/show_bug.cgi?id=90172
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Once we have a doubletap, enter a loop in the state machine where we can tap
multiple times and either get a multi-click or a multi-click drag-and-drop.
The sequence down/up down/up down/up produces a triple-click. The sequence
down/up down/up down/up down produces a triple-click with a button down for
dragging. Yes, that glorious octuple-tap-and-drag, it is now possible. World
domination has been achieved, thank you for playing.
We don't know when we finish tapping now, so add a timeout to send the last
click event once the finger has been released for the last time. This
guarantees that the timestamp of the last button down is later than the
last release. This avoids the bug fixed in synaptics commit
xf86-input-synaptics-1.8.0-21-g37d34f0 (some application don't handle
doubletap correctly without the timestamps).
This works for double-tap immediately, for multi-tap we need to remember the
timestamp of the first press event and use it for the release event so that
there's a forced gap between the release and the second press.
https://bugs.freedesktop.org/show_bug.cgi?id=89511
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Touches in the exclusion zone are ignored for palm detection and don't move
the cursor. Tapping however triggers before we know whether something is a
palm or not, so we get erroneous button clickst.
If a tap happens in the top half of the touchpad, within the palm exclusion
zones, ignore it for tap purposes. To avoid further complicating the state
machine simply pretend there was a movement > threshold on that finger. This
advances the tap state machine properly that no button events are sent for
this finger.
https://bugs.freedesktop.org/show_bug.cgi?id=89625
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
tp->nfingers_down gives us the current state of the touchpad but in the case
of the tapping state we need the touchpoints separately. If all touchpoints
end in the same SYN_REPORT frame, tp->nfingers_down is 0 when we handle the
touch releases. This changes the tap state to IDLE on the first release and
then logs a bug when the remaining touches are released while the touchpad is
in IDLE.
Avoid this by counting the fingers separately for the tap state, this way we
can count up/down with the down/up events as we process them for the tapping
state machine.
This also adds tests for 4 and 5-finger tapping which is how the bug was
discovered in the first place.
https://bugs.freedesktop.org/show_bug.cgi?id=89800
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Add a normalized_length helper function and use this where applicable,
just a minor cleanup.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tp_normalize_coords is one of the last functions taking separate x, y
values rather a coordinate pair, this commit cleans this up.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
