Most scroll motions would be labelled a palm.
https://bugs.freedesktop.org/show_bug.cgi?id=90980
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>
On touchpads with resolutions, use a 5mm motion threshold before we unpin the
finger (allow motion events while a clickpad button is down). This should
remove any erroneous finger movements while clicking, at the cost of having to
move the finger a bit more for a single-finger click-and-drag (use two fingers
already!)
And drop the finger drifting, it was per-event based rather than time-based.
So unless the motion threshold was hit in a single event it was possible to
move the finger around the whole touchpad without ever unpinning it.
Drop the finger drifting altogether, if the touchpad drifts by more than 5mm
we have other issues.
https://bugzilla.redhat.com/show_bug.cgi?id=1230462
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The current code labels a touch as palm if it started within the typing
timeouts. To move the pointer even after the timeout expires, a user has to
lift the finger which is quite annoying and different to the old synaptics
driver behaviour (which had a simple on/off toggle on whether to let events
through or not).
Be smarter about this: if a touch starts _after_ the last key press event,
release it for pointer motion once the timeout expires. Touches started before
the last key press remain labelled as palms. This makes it possible to rest
the palm on the touchpad while typing without getting interference but also
provides a more responsive UI when moving from typing to using the touchpad
normally.
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>
Check a couple of easy yes/no definitives that cover most Lenovo laptops,
and avoid false positives on Wacoms.
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>
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>
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>
On some touchpads, typing triggers touches in areas of the touchpad that
cannot easily be distinguished from other fingers. Pressure information is
useless too, so we have to go back to a timeout-based handling of touch data.
If we see non-modifier key events, disable the touchpad for a timeout and set
any touches starting during that timeout as palm.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Preparation to add different palm detection types. Not all of them need to be
un-done when leaving the edge area so a boolean is not enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.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>
When the device supports true hovering, it reports this
information through ABS_MT_DISTANCE.
When this axis is available, we should rely on it to
(un)hover the touches as BTN_TOUCH is most of the time
unreliable (generated by the mouse emulation in the kernel).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
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>
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>
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>
What we really need is not a specific delta type, but a type which can hold
non discrete device coordinates, this is e.g. also needed for the center
coordinates of gestures. So rename delta_coords to device_float_coords to
properly reflect what we really need.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
This way the unaccelerated deltas returned by libinput are correct.
To maintain the current behavior we slow down the input speed by the magic
factor and likewise the accelerated output speed. This produces virtually the
same accelerated deltas as the previous code.
The magic factor is applied to the default denominator for guessing a
resolution based on the touchpad diagonal. We can't really get around this
without having a resolution from the touchpad; meanwhile this produces
virtually the same coordinates before/after.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Now that we've separate handling of the EDGE_NEW vs EDGE states in
tp_edge_scroll_post_events() we can drop the threshold variable, in EDGE_NEW
we always want to check against DEFAULT_SCROLL_THRESHOLD and in the EDGE
state we only want to make sure that the delta != 0.0 which is already
checked later on in tp_edge_scroll_post_events().
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>
The previous setting of 10 wasn't 10 mm, it was used against the deltas
normalized to a 1000DPI mouse, i.e. closer to 4mm. It was also also per-event,
so a slow movement or a high-frequency touchpad can struggle to meet the
threshold.
Change the trigger to be ~5 mm from the initial touch down, accumulated until
we either meet the threshold or the timeout expires. The first scroll event
includes the delta since the touch down rather than the most recent delta.
This removes the delay otherwise seen in scrolling and makes the scroll motion
match the finger motion. This accumulated delta only applies when exceeding
the motion threshold, when the timeout triggers the switch to scrolling the
first delta posted is the current delta.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Previous code used a device coordinate threshold of 300 which won't work on
Elantech touchpads (1280 vs the ~4000 that synaptics has).
Convert to normalized DPI and reduce the threshold to 3mm.
https://bugs.freedesktop.org/show_bug.cgi?id=89206
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ideally we want to specify various thresholds in mm, but not all touchpads
set the hardware resolutions. Rather than conditions to check for resolutions
everywhere, use a macro to give us a normalized value that we use for motion
as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
All callers except the tap motion threshold call
tp_get_delta() followed by tp_filter_motion() - the latter normalized it
before calling into the accleration code.
Move the normalization into tp_get_delta() so we don't deal with
device-specific coordinates but normalized deltas instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Just moving some code around, no functional changes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Handle everything which is not handled by the tap, (soft)button or edge-scroll
code/statemachines in a unified way. Everything is treated as a X-finger
gesture now, and the action to take on finger movement is decided by
the gesture.finger_count setting. Pointer control now simply is seen as a
1 finger gesture, and 2fg scrolling as a 2fg gesture.
This removed the need for special-casing things like switching back to
pointer mode when lifting a finger in 2fg scrolling mode, and also lays the
groundwork for adding 3+ fg gesture support.
Note that 1 test-case needs to be updated to wait for the finger mode
switching when switching mode while a gesture has already been started.
This is actually an improvement as this stops sending spurious pointer
motion events at the end of 2fg scrolling when not lifting both fingers at
exactly the same time.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Allow switching between softbuttons and clickfinger on any mt-capable
clickpad.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[hdegoede@redhat.com] Keep top softbuttons working when enabling clickfinger
[hdegoede@redhat.com] Simply touchpad click method switching
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Some touchpads provide touch information while the finger hovers over the
touchpad, i.e. before BTN_TOUCH. Add a touch state for those touchpads so we
can ignore the touches until they actually start.
The approach is now: instead of BEGIN we mark a new touch as HOVERING.
Use the BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP information during
tp_process_state() to mark any touches that are hovering as down or ended.
i.e. provided BTN_TOUCH is down: if BTN_TOOL_FINGER is down, one hovering
touch gets marked as down, if DOUBLETAP is down, two touches are marked as
down, etc.
When ending touches, switch them back into HOVERING if the BTN_TOOL_FINGER
is still set, otherwise end them properly.
https://bugs.freedesktop.org/show_bug.cgi?id=87197
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We need this for determining hovering touches on some semi-mt touchpads.
This makes the fake_touches mask use bit 0 for BTN_TOUCH, and the other bits
for BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP, etc. BTN_TOUCH is independent of the
rest, the others are mutually exclusive in the kernel.
Since the mask isn't a straightforward bitmask anymore, abstract it all
through helper functions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Add a boolean state machine for two-finger scrolling so we know when we're
currently scrolling. If we were scrolling and it stops, pick the active
touch as pointer touch so we can go back to pointer movement without having to
lift the finger off the touchpad.
https://bugs.freedesktop.org/show_bug.cgi?id=86807
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We use 2 mechanisms to unregister the trackpoint event listener depending on
device removal order.
1) We have a device_removed callback, if the trackpoint gets removed before
the touchpad, this gets called, sees the device being removed is the trackpoint
and unregisters the listener
2) If the touchpad gets removed first, then in tp_destroy we unregister the
listener
2) May be delayed beyond the destruction of the trackpoint itself if the
libinput user has a reference to the libinput_device for the touchpad.
When this happens the trackpoint still has an eventlistener at destroy time
and an assert triggers.
To fix this we must do 2) at the same time as we do 1), so at remove time.
While working on this I noticed that the touchpad code was also cancelling
timers at destroy time rather then remove time, which means that they may
expire between remove and destroy time, and cause events to be emitted from
a removed device, so this commit moves the cancelling of the timers to the
remove callback as well.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
For certain applications (such as FPS games) it is necessary to use
unaccelerated motion events (the motion vector that is passed to the
acceleration filter) to get a more natural feeling. Supply this
information by passing both accelerated and unaccelerated motion
vectors to the existing motion event.
Note that the unaccelerated motion event is not equivalent to 'raw'
events as read from devices.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add edge-scrolling support for non multi-touch touchpads as well as for
users who prefer edge-scrolling (as long as they don't have a clickpad).
Note the percentage to use of the width / height as scroll-edge differs from
one manufacturer to the next, the various per model percentages were taken
from xf86-input-synaptics.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=85635
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>
This is useful to know in some cases, it is e.g. necessary to figure out
which percentage of a touchpads range to use as edge for edge-scrolling.
Note this is a slightly cleaned up copy of the same code in
xf86-input-synaptics.
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>
We're about to add natural scroll support to other devices as well, let's
share the code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Default to 2fg scrolling for now, once we have edge-scrolling we can default
to edge-scrolling on touchpads which cannot detect more than 1 touch.
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>
To avoid confusion with scroll mode configuration.
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>
The touchpad tap code explicitly supports 2 finger tap-n-drag, this commit
adds a test-case for this, which fails due to the 2 finger scrolling code
sending scroll events during a 2 finger tap-n-drag.
And this commit fixes the test-case, by not sending scroll events while a
tap-n-drag is active.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Some laptops with both a clickpad and a trackpoint have such a large touchpad,
that parts of the users hands will touch the pad when using the trackpoint.
Examples of this are the Lenovo T440s and the Toshiba Tecra Z40-A.
This commit makes libinput automatically disable the touchpad while using
the trackpoint on these devices, except for the buttons, as people may want
to use the touchpad (hardware or soft) buttons while using the trackpoint.
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>
While e.g. disabling the touchpad while the trackpoint is used, we want to
stop sending tap (or scroll or motion) events. We cannot use tp_clear_state at
this time as that will also release any touchpad buttons pressed, breaking
dragging with the trackpoint using the touchpad or clickpad buttons.
Calling tp_release_all_taps() and then ensuring that we do not call
tp_tap_handle_state as long as the trackpoint is in use, is enough to disable
taps when the trackpoint is in use.
However when the trackpoint stops being used, we cannot simply start calling
tp_tap_handle_state() again, we first need to sync the tap.state to the current
reality, specifically if fingers are down it must be TAP_STATE_DEAD, so that
their releases do not trigger the log_bug_libinput on a release in
tp_tap_idle_handle_event.
Directly messing with tap.state from outside evdev-mt-touchpad-tap.c is not
good, so add tp_tap_suspend and tp_tap_resume functions for this.
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>
