When the filter code switched to raw device coordinates (bdd4264d) the input
data remained in device coordinates. Since the factor for touchpads was still
based on the physical velocity (and thus all touchpads get the same
acceleration factor for identical moves), the actual delta was dependent on
the resolution. e.g.
touchpad with 40u/mm: delta of 2/2 * accel factor 2 -> accel delta of 4/4
touchpad with 20u/mm: delta of 1/1 * accel factor 2 -> accel delta of 2/2
The normalized coordinates should be independent of the touchpad's resolution
though.
Affected by this was the standard mouse accel code and the touchpad accel
code, other filters always returned unnormalized coordinates (separate bug,
not addressed here).
This patch restores the correct behaviour for mice and touchpads
while leaving the special filters untouched. For comparision:
* 1000+dpi mice: accelerate normalized, return normalized
* touchpads: accelerate unnormalized, return normalized
* low-dpi mice: accelerate unnormalized, return unnormalized
* trackpoints: accelerate unnormalized, return unnormalized
* x230: don't touch, already does the right thing
https://bugs.freedesktop.org/show_bug.cgi?id=99383
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We were just switching type here without actual normalization, the filter code
is in device units as of bdd4264d61.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Could be confirmation bias, but it feels better.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous code had three main issues:
* acceleration kicked in too early, so even slow movements were accelerated
* acceleration kicked in too quickly, there was only a very narrow window
where we would have less than the max acceleration factor
* the max accel factor was too low for fast movements, so they still fell
short of expectations
This patch revamps most of the acceleration though it keeps the basic shape of
the acceleration curve.
* The threshold is increased significantly so that faster movement
still map to the finger movement. Acceleration doesn't kick in until we get
to something that's really fast like a flick.
* The incline is dropped, so acceleration kicks in slower than before, i.e.
the difference between the first speed that is accelerated and the speed
that reaches the maximum is higher than before.
* The maximum acceleration is increased so ever faster movements get ever
faster. The max is effectively out of reach now, if you move fast enough to
hit this speed, your cursor will end up on the moon anyway.
A couple of other changes apply now too, specifically:
* The incline remains the same regardless of the speed
* The max accel factor remains the same regardless of the speed
The caculated factor changes with the speed set so that the base speed changes
with the desired speed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We have everything separate from the mouse now, so having a magic slowdown
isn't needed, we can work this into our parameters. So the acceleration
function now uses everything adjusted, but the factor is still multiplied by
the slowdown in the end.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
That's something human brains can map to because mapping a touchpad to
equivalent units of a 1000dpi mouse requires a lot of mental acrobatics. And
I'm getting older and my physio told me acrobatics is more something for the
youngens, possibly those on my lawn listening to terrible music, etc.
The various numbers are converted either times 25.4/1000 or times 1000/25.4,
depending on the usage. Somewhere I made a mistake or a rounding error or
something, so the acceleration curve is not exactly the same, but it's close
enough that it shouldn't matter. The difference shows up in a gnuplot of the
curve but it may not even perceivable anyway. And these values will be
overhauled soon anyway, so meh.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The profile is what is still special about those two, the filter itself does
the same as the default filter (calculate velocity, calculate accel factor,
apply to delta).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This duplicates the code so we can change it for touchpads without affecting
mice.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This was badly since the factor was the ratio of "dpi:default dpi"
Most devices don't need it, so storing it in all filters event though we only
use it for some devices is confusing. Now that we have the dpi stored
directlyconfusing. Now that we have the dpi stored directly we might as well
use that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Currently unused, will be used in the future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The current code tried to emulate the relative motion to be equivalent to the
absolute motion, except in screen coordinates. This is way too slow for the
cursor tool that we want to behave like a mouse.
Tablets have high resolution (e.g. an Intuos 4 is a 5080dpi mouse) and that
motion is way too fast to be usable. Scale it down to match a 1000dpi device
instead. Since the cursor and lens tool are still high precision devices leave
them in a flat acceleration profile without actual acceleration.
For the stylus-like devices leave the current accel, pointer acceleration on a
stylus is hard to handle.
This also adds the missing bits for actually using the speed factor set
through the config interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
The quartett of new config functions is:
libinput_device_config_accel_get_profiles
libinput_device_config_accel_get_profile
libinput_device_config_accel_set_profile
libinput_device_config_accel_get_default_profile
The profile defines how the pointer acceleration works, from a very high-level
perspective. Two profiles are on offer, "adaptive", the standard one we have
used so far and "flat" which is a simple multiplier of input deltas and
provides 1:1 mapping of device movement vs pointer movement.
The speed setting is on top of the profile, a speed of 0 (default) is the
equivalent to "no pointer acceleration". This is popular among gamers and
users of switchable-dpi mice.
The flat profile unnormalizes the deltas, i.e. you get what the device does
and any device below 800dpi will feel excruciatingly slow. The speed range
[-1, 1] maps into 0-200% of the speed. At 200%, a delta of 1 is translated
into a 2 pixel movement, anything higher makes it rather pointless.
The flat profile is currently available for all pointer devices but touchpads.
https://bugs.freedesktop.org/show_bug.cgi?id=89485
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The x230 has a special acceleration method that relies on the touchpad magic
slowdown. This was missing from commit c8da19b50a, making two-finger
scroll motions unusably fast
https://bugs.freedesktop.org/show_bug.cgi?id=91819
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>
For when we need to apply some transformation to the data but it shouldn't be
acceleration. Example use are touchpad coordinates, even when not
accelerating, we still want to apply the magic slowdown.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Requires splitting out the X230 one so we don't accidentally break things if
we ever change this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is step one to fixing trackpoint acceleration, separating it from the
other acceleration code. No functional changes yet, it still uses the low-dpi
accel method.
https://bugs.freedesktop.org/show_bug.cgi?id=91369
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This is "once-tested, don't touch it again" code. The quirks on the touchpad
means we'd have to find that specific device again and re-test everything if
we change anything elsewhere in the code. So duplicate it properly, so that we
don't have to touch it again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
The previous approach to pointer acceleration was to initialize the same
motion filter behavior but a different acceleration profile depending on the
hardware (the profile converts a speed to a multiplier for input deltas).
To be more flexible for hardware-specifics, change this into a set of specific
pointer acceleration init functions. This patch has no effective functional
changes, they're still all the same.
The acceleration functions are kept for direct access by the ptraccel-debug
tool.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
No functional changes, just moving code in preparation for filter patches
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
And switch to a code-flow that's a bit more self-explanatory than the current
min/max combinations.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This makes it more obvious where we're using units/us and units/ms as input
variable and what the output is. Clutters up the code, but still better than
dealing with us/ms differently per function, and still better than carrying
all the 1000.0 multiplications/divisions manually.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
The return value of a profile is a unitless factor, not a speed.
Same applies for s1/s2, these are factors, not speeds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This reverts commit 8a6825f160.
Aside from introducing bugs, this doesn't really help with anything, it adds a
requirement to rename everything to make clear where we're using µs and where
we're using ms and that just clutters up the code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
The new values were in units/us and didn't make the switch back to ms in
8a6825f160.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
There is no need here to use µs since we're just handling speeds/thresholds,
not actual events where a ms granularity can be too high.
Moving back to ms lets us drop a bunch of zeroes that clutter up the code, and
since the acceleration functions are a bit magic anyway, having the various
1000.0 factors in there makes it even less obvious.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.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>
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>
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>
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>
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>
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>
