Motion normalization does not work well for devices below the default 1000dpi
rate. A 400dpi mouse's minimum movement generates a 2.5 normalized motion,
causing it to skip pixels at low speeds even when unaccelerated.
Likewise, we don't want 1000dpi mice to be normalized to a 400dpi mouse, it
feels sluggish even at higher acceleration speeds.
Instead, add a custom acceleration method for lower-dpi mice. At low-speeds,
one device unit results in a one-pixel movement. Depending on the DPI factor,
the acceleration kicks in earlier and goes to higher acceleration so faster
movements with a low-dpi mouse feel approximately the same as the same
movement on a higher-dpi mouse.
https://bugzilla.redhat.com/show_bug.cgi?id=1231304
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Currently unused, but store the ratio of DPI:default DPI for later use.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.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>
Deceleration at low speeds is intended to enhance precision when moving the
pointer slowly. However, the adaptive deceleration we used was badly
calibrated, at slow-but-normal speeds the pointer became too slow to manouver.
We don't want to drop deceleration completely, the subpixel precision it
provides is useful. And it also helps those that can't move a 1000dpi mouse by
exactly one unit.
Make the adaptive deceleration steeper so it only kicks in at extremely slow
motions and defaults to 1 at anything resembling normal movement (i.e. pointer
moves like the physical device does).
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>
We use width/height often enough that storing it once is better than
calculating it on each event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On a touchpad without resolution, the pinned finger was stuck. The motion
distance scale factor ended up as 0 and the finger never reached the threshold
of 3mm.
int was not the best choice of datatype for a value of 0.007...
Fix the data types for xdist/ydist at the same time, clamping to int may cause
erroneous (un)pinning.
Introduced in 8025b374d5https://bugs.freedesktop.org/show_bug.cgi?id=91070
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When edge scrolling is triggered by exceeding the motion threshold (5mm) we
sent the whole delta as the first scroll event, causing a big jump.
Instead, send only the current delta. This effectively introduces a 5mm dead
zone when edge scrolling, still better than the jump.
https://bugs.freedesktop.org/show_bug.cgi?id=90990
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>
Alps devices don't know if there is a physical middle button on the touchpad,
so they always report one.
Since a large number of touchpads only have two buttons, enable middle button
emulation by default. Those that really don't want it can play with
configuration options, everyone else has it working by default.
The hwdb entry uses "*Alps ..*" as name to also trigger the "litest Alps..."
devices.
https://bugzilla.redhat.com/show_bug.cgi?id=1227992
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
This caused the finger to be unpinned on the first motion event after the
click, effectively disabling this feature.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Some touchpads, e.g. the Cyapa in the Acer c720 have a small axis range
([0, 870], [0, 470]), so the diagonal/magic value yields a hysteresis margin
of 1 device unit. On that device, that's one-tenth of a millimeter, causing
pointer motion just by holding the finger.
For touchpads that provide a physical resolution, set the hysteresis axes to
0.5mm and do away with the magic factor.
https://bugzilla.redhat.com/show_bug.cgi?id=1230441
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For really slow motions, the previous acceleration factor would go down to
effectively zero. So the slower the mouse motion was, the more it would be
slowed down which made the mouse at low speeds almost unusable.
Cap the minimum acceleration at 0.3 which provides a predictable slow motion
for the cursor when high precision is required.
New/old acceleration functions comparison:
^
| /
| /
ty| _________/
| / /
| / /
| / /
|/ / <----- new minimum accel factor
| /
|/___________________>
tx
i.e. the general shape is maintained, but it doesn't go to zero anymore. The
functions aren't parallel, the new shape is slightly flatter than the previous
one and they meet at the point where the functions flatten for the threshold
(tx/ty). ascii art has its limits...
https://bugzilla.redhat.com/show_bug.cgi?id=1227039
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Our motion filter takes the last couple of vectors to calculate speed,
provided the direction stays the same and it is within a certain timeout. It
does not take into account lifting the finger, so the velocity on the first
event is off.
Real-world impact is mainly on scrolling. Before commit 289e4675
filter: enforce minimum velocity
the first motion on a scroll was accelerated by a factor of 0 and swallowed.
After 289e4675 the motion was calculated based on the timeout and a fraction
of the expected effect. Now the first scroll motion is based on the real
finger motion since setting the finger down and thus feels a bit more
responsive.
It also makes a couple of test cases using litest_assert_scroll() work again
since the miniumum motion is now as expected.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
