This timeout is there to switch to scrolling when the fingers rest on the
touchpad unmoving and thus avoids the initial scroll threshold for slow
scrolls.
Since the only other gestures we support are swipe (usually a fast movement)
and pinch-and-rotate (also a fast movement) we can drop the timeout down
significantly and thus make the scroll feel more reactive.
https://bugs.freedesktop.org/show_bug.cgi?id=93504
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>
Increase the mm move threshold for 3 and 4 finger gestures to 2 and 3 mm,
respectively. In multi-finger gestures it's common to have minor movement
while all fingers are being put down or before the conscious movement starts.
This can trigger invalid gesture detection (e.g. a pinch instead of a swipe).
Increase the movement threshold to make sure we have sufficient input data.
No changes to 2-finger movements.
https://bugs.freedesktop.org/show_bug.cgi?id=96687
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A natural hand position for a 4-finger swipe will have one finger well below
the other triggering the pinch detection. This is obviously wrong, only do the
finger position analysis when we have 2 fingers.
This is only a partial fix, for 3-4 finger gestures chances are high that the
third/fourth finger come in a different event frame. Before that we likely
detect 2 fingers in a possible pinch position and still trigger the code path.
This issue has to be fixed separately.
https://bugs.freedesktop.org/show_bug.cgi?id=96687
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Introduced in 6ad303b as part of an code flow optimization, causing any 3+
finger gesture to be posted as swipe gesture, even when gestures are disabled.
However, the event is filtered in the higher levels with a bug message printed
to the log.
Don't post swipe gestures for devices where gestures are disabled.
https://bugs.freedesktop.org/show_bug.cgi?id=95314
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Because our delta calculation factors in previous events on touchpads (to
reduce jitter) we may get a nonzero delta if we have an event that doesn't
actually change x or y.
Drop the t->dirty workaround introduced in a608d9d, an event that virtually
disappears can mess up our state machines.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If the fingers are vertically apart by more than 20mm we used to assume a
pinch gesture immediately. This is too close together for some users during
two-finger scrolling. Since we should always bias towards scrolling, only
trigger this detection for three fingers, the rest has to go through the
movement detection.
The reason for the pinch detection here was to differentiate from 3fg swipe
gestures (83f3dbd1), hence we're still in spirit of that patch.
https://bugs.freedesktop.org/show_bug.cgi?id=94264
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
When two fingers move slowly, an event frame may only have one finger motion,
followed by a frame with the other finger's motion. If we only divide by the
number of dirty touches, the speed of the gesture increases whenever that
happens.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The first/second variables are only needed for pinch, so we can skip them
here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No point trying to detect pinch gestures if we only have one set of
coordinates. This makes two-finger scrolling on ST touchpads more reactive.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Synaptics, Elantech and Alps semi-mt devices all have issues with reporting
correct MT data, even the bounding box which semi-mt devices are supposed to
report is wrong.
Synaptics devices have massive jumps with two fingers down. Elantech devices
may open slots without coordinate data. Alps devices may send 0/0 coordinates
as initial slot position.
All these may be addressable with specific quirks, but the actual benefit is
largely restricted to better palm detection (though even with quirks this is
unlikely to work) and support for pinch gestures (again, lack of coordinates
makes supporting those hard anyway).
Elantech: https://bugs.freedesktop.org/show_bug.cgi?id=93583
Alps: https://bugzilla.redhat.com/show_bug.cgi?id=1295073
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Pure movement detection is quite unreliable when trying 3-finger pinch
gestures, and many gestures are misdetected as swipes. Before looking at the
motion, look at the constellation of the fingers. If one finger is 20mm below
the other one, assume they're in a pinch position.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least on the t440, this is enough to trigger correct detection between
pinch and scroll 90% of the time. Since scrolling is significantly more
prevalent than gesturing, erring on the side of scrolling at the cost of
misdetecting some gestures is acceptable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For short and quick scroll gestures, those that should only trigger a few
lines of scroll the pointer acceleration is wildly unpredictable. Since we
average the motion of both fingers it's hard enough to intuitively predict
what the motion will be like. On top of that is the small threshold before we
start scrolling, so some of the initial motion gets swallowed before we
accelerate, making the next motion even more unpredictable.
The end result is that multiple seemingly identical finger motions cause
wildly different scroll motion.
Drop pointer acceleration for two-finger and edge scrolling. This makes short
scroll motions much more predictable and doesn't seem to have much effect on
long scroll motions. Plus, in natural scroll mode it really feels like the
content is stuck to your fingers now. Go wash your hands.
https://bugzilla.redhat.com/show_bug.cgi?id=1249365
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Holding the fingers in place without moving for 500ms is long enough to lock
in a scroll gesture, especially while we're still waiting for the rest of the
stack to expose pinch gestures.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Unlike ALPS and Synaptics semi-mt touchpads, the Elantech touchpads appear to
be precise enough to allow a smaller motion threshold before we decide on the
type of gesture (pinch vs scroll).
https://bugs.freedesktop.org/show_bug.cgi?id=91475
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Follow-up to eb146677e, if we disable 2fg scrolling on those touchpads we
should also disable gestures. The data doesn't magically become more useful.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Not all multi-finger touchpads are able to reliably produce gestures, so make
it optional. This patch just adds a boolean (currently always true) that gets
set on touchpad init time, i.e. it is not run-time configurable.
Three and four-finger gestures are filtered out in gesture_notify(), if the
cap isn't set the event is discarded.
For two-finger gestures we prevent a transition to PINCH, so we don't
inadvertently detect a pinch gesture and then not send events. This way, a 2fg
gesture is always scroll.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This gives us too many false positives of 2fg scroll being detected as pinch
gesture. Reporter in [1] uses index+ring finger and thus exceeds the distance
easily (that's admittedly a special case).
This is worsed by the lack of a client stack that handles the gestures. User's
don't see that they're inadvertently performing a gesture, they just see 2fg
scroll not working.
Drop the distance for now, once we have a ubiquitous client stack we can
revisit and bring it back.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1246868
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We need to check fake fingers as well as real fingers, especially for
two-finger scrolling on single-touch touchpads with BTN_TOOL_DOUBLETAP.
https://bugzilla.redhat.com/show_bug.cgi?id=1246651
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>
3mm is too large, especially on fine-grained scroll motions. Since we
already use the hysteresis to defuzz the current touchpad point, having a
slower threshold here should not cause any adverse motions.
This affects the pinch gestures too and needs a minor test adjustment. The
atmel hover device's resolution is low enough that we trigger a >1 degree
angle now, make the movement a bit more finegrained.
https://bugs.freedesktop.org/show_bug.cgi?id=91364
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Thumb detection interfered with gestures a fair bit but it shouldn't. A pinch
gesture with a thumb is a fairly natural move so we shouldn't cancel that.
A swipe gesture with a thumb on the touchpad - well, don't do that. No need
for code here.
Reported-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
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>
Implement touchpad pinch (and rotate) gesture support.
Note that two two-finger scrolling tests are slightly tweaked to assure that
there is enough touch movement to allow the scroll-or-pinch detect code to do
its work.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Add support for swipe gestures.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
This simply doesn't work for low-dpi mice. Normalizing a 400dpi mouse to a
1000dpi mouse forces a minimum movement of 2.5 units and the resulting pixel
jumps. It is impossible for the caller to detect whether the jump was caused
by a single motion or multiple motion events.
This is technically an API break, but not really.
The accelerated data was already relatively meaningless, even if normalized as
the data did not correspond predictably to any input motion (unless you know
the implementation acceleration function in the caller). So we can drop the
mention from there without expecting any ill effects in the caller.
The unaccelerated data was useless for low-dpi mice and could only be used to
measure the physical distance of the mouse movement - something not used in
any caller we're aware of (if needed, we can add that functionality as a
separate call). Dropping motion normalization for unaccelerated deltas also
restores true dpi capabilities to users of that API, mostly games that want to
make use of high-dpi mice.
This is a simplified patch, the normalization is still in place for most of
libinput, it merely carries the original coordinates in the event itself.
In the case of touchpads, the coordinates are unnormalized into the x-axis
coordinate space as per the documentation.
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>
Some semi-mt model touchpads have a better accuracy for slot 0 then for
slot 1 (they only have 2), so on semi-mt models only use the movement of
the touch in slot 0 for 2fg scrolling, rather then the average movement of
the 2 touches.
This fixes 2fg scrolling being choppy / jumpy in some cases.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=89683
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Also needed: change the touchpad scroll source test to use more separate
events. The current litest semi-mt touch implementation only moves the first
touch on every second move. With 5 movements this isn't enough to fill the
motion history and generate events, so double it to 10 so we're guaranteed to
get scroll events.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Less ambiguous since real_touches can be interpreted to "current number of
real touches as opposed to fake touches". Which it isn't, this variable holds
the number of slots.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Change tp_filter_motion to use normalized_coords, rather then having it take
separate x and y values.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a normalized_is_zero helper function, and use it where applicable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
