A common use-case for clickfinger is to use the index finger for moving the
pointer, then triggering the click with a thumb. If the index finger isn't
lifted before the click this counted as two-finger click.
To avoid this, check the distance between touches on the touchpad (on
touchpads reporting resolution values anyway). If the touches are too far
apart, don't count them together (or specifically only count those close
enough together as multi-finger).
The touch area is uneven, it's wider than high. Spreading fingers horizontally
is more common and this also makes it easier to rule out thumbs which tend to
be well below the fingers.
http://bugs.freedesktop.org/show_bug.cgi?id=90526
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If we need to temporary override a device with ID_INPUT_POINTINGSTICK,
evdev sets the tag EVDEV_TAG_TRACKPOINT to the device. Rely on the tag
to behave properly for scroll emulation.
The dpi information should be retrieved after the device has been
configured or the tag EVDEV_TAG_TRACKPOINT was not set.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tagging a device should occur only once during configure. We do not
have devices that can be changed after they are configured, so there is no
point in having the tagging part in a deferred struct.
Plus, the note saying that we tag with only one of EVDEV_TAG was wrong.
Now that we are chosing when we call each evdev_tag_*, we can also get
rid of the device->seat_caps tests.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code only defaulted to the middle button for those devices that
used button scrolling by default, requiring the user to enable button
scrolling _and_ set the button before it is active. This causes some
confusion.
There is no real benefit to leaving the button at 0 when the scroll
method isn't enabled anyway. So always default to the middle button (if
available).
https://bugzilla.redhat.com/show_bug.cgi?id=1227182
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.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>
In the current code, a timeout or direction change on the first tracker will
result in a velocity of 0. Really slow movements will thus always be zero, and
the first event after a direction is swallowed.
Enforce a minimum velocity:
In the case of a timeout, assume the current velocity is that of
distance/timeout. In the case of a direction change, the velocity is simply
that since the last tracker.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This timeout defines how far back in the events we search for velocity
calculations. For really slow movements, 300ms is not enough. It causes the
velocity to be 0 -> accel factor of 0 -> no movement.
As a result, really slow movement does not move the cursor.
Up the timeout to 1 second instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Let the caller set the various fields, here we just calculate stuff.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
When we get the release event within the timeout, we send a press + release
event for the middle button. Rather than using the release event's timestamp
for both, remember and use the button press timestamp.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If asprintf fails for any reason, the contents of the pointer
are undefined. While some platforms set it to NULL, there is no
guarantee that all will.
This change adds a simple wrapper to ensure proper NULL results
on failure.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Added LIBINPUT_PRINTF attribute and the required declaration for it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Added in systemd 220, but note that for udev backwards compatibility, the
ID_INPUT_POINTINGSTICK tag is set in addition to the ID_INPUT_MOUSE tag.
And use that property to tag a device as trackpoint too, this allows temporary
workarounds for kernel bugs where the input prop isn't set yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1225563
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a relative device is tagged by udev as ID_INPUT_TOUCHPAD we need to
catch this before we try to dereference device->abs.absinfo_x.
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>
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>
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>
The keyboard test is a simple one, if we have the first row of alphabetic
keys, we assume it's a full keyboard.
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>
Alt-tab should not trigger the disable-while-typing timeout, likewise with the
F-keys, multimedia keys, the windows and menu key, etc.
https://bugs.freedesktop.org/show_bug.cgi?id=90613
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>
Unlikely, but there's the odd chance of the first touch coming in with the
same X or Y coordinate the kernel already has internally. This would
generate a bogus delta on the second event when the touch coordinate jumps
from 0/y or x/0 to the real coordinates.
For touchpads with distance support this is a real issue since the default
value for a touch distance is > 0.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Unlikely, but there's the odd chance of the first touch coming in with the
same X or Y coordinate the kernel already has internally. This would generate
a x/0 or 0/y event in libinput.
Sync the slot state on init, at least for Protocol B devices. For Protocol A
devices and mtdev, don't bother.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The touchpad carries enough state around that calling release_all_keys() isn't
enough to properly suspend it. e.g. a button down after tapping won't be
released by trying to release the physical button for it.
We need to clear the state properly, but that's interface-specific so add a
new hook for it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Just a move to make the next diff easier
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Add "interface" to the name to make things a bit clearer.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a physical button is down but releasing said button doesn't actually
release it, we loop endlessly. Detect that and log a bug instead.
Reproducible: trigger a tap-n-drag on a touchpad device, then remove it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The System76 Galago Ultra Pro is a rebranded Clevo W740SU with changed
firmware strings. To my knowledge, the Clevo W740SU and all its rebrands
possess smooth touchpads.
In the original bug report[1], a Galago Ultra Pro was returned to the
original DMI strings by flashing another firmware. This resulted in the
model identified as MODEL_SYSTEM76_CLEVO.
Since the actual manufacturer of the W740SU is Clevo and the CLEVO hwdb
entry already properly identifies other W740SU rebrands like the Schenker
S413, the model should be renamed to match.
[1]: https://bugs.freedesktop.org/show_bug.cgi?id=90170#c3https://bugs.freedesktop.org/show_bug.cgi?id=90353
Signed-off-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Running tests in parallel can exceed the current 100ms max timeout for udev to
settle things. Since this pretty much only triggers in test cases anyway,
let's be more lenient here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Hitting a single key triggers a short timeout, just enough to cover the time
to the next key event. Hitting more than one key triggers the longer timeout.
This should improve responsiveness after single key events when the touchpad is
still the main interaction mode and a key needs to be pressed to advance in
the UI. When typing the hands require physical movement to get back to the
touchpad anyway so a longer timeout is acceptable and more reliable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.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>
"read(int, void *, size_t)" returns the number of bytes read, but it
is ignored.
We don't really care about the number of bytes, but let's complain if we get
anything but EAGAIN.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
This code was largely lifted from the X server in
bb25b2ad29 but didn't take the copyright messages that
applied to that code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Simon Thum <simon.thum@gmx.de>
