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>
Those touchpads presents an actual lower resolution that what is
advertised.
We see some jumps from the cursor due to the big steps in X and Y
when we are receiving data.
For instance, we receive:
E: 13.471932 0003 0000 16366 # EV_ABS / ABS_X 16366
E: 13.471932 0003 0001 9591 # EV_ABS / ABS_Y 9591
E: 13.471932 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 13.479924 0003 0000 16316 # EV_ABS / ABS_X 16316
E: 13.479924 0003 0001 9491 # EV_ABS / ABS_Y 9491
E: 13.479924 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 13.487939 0003 0000 16271 # EV_ABS / ABS_X 16271
E: 13.487939 0003 0001 9403 # EV_ABS / ABS_Y 9403
E: 13.487939 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
-> jumps of ~50 in X in each report, and ~100 for Y.
Apply a factor to minimize those jumps at low speed, and try
keeping the same feeling as regular touchpads at high speed.
It still feels slower but it is usable at least
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The main purpose of this patch is to allow the user to actually slow
down pointer movement using libinput_device_config_accel_set_speed, this
is achieved by changing the max-accel setting from "2.0 - speed" to
"2.0 - speed * 1.5", resulting in a max-accel of 0.5 when the user configures
speed at -1.0, the other accel profile parameters are adjusted by the same
factor to keep the curve the same.
This means that the user can get the exact same behavior as before by
multiplying the old setting by 0.6667 (2/3), this also means that this
change not only allows the user to select a slower speed, but to keep
things balanced the same as before, also a higher speed.
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>
Change vector_get_direction input to a normalized_coords type rather than
passing in a separate x,y pair, and rename it normalized_get_direction to
match. Since it now depends on the normalized_coords type which gets declared
in libinput-private.h also move it to libinput-private.h .
Note this commit also contains a functional change wrt the get_direction
usuage in the palm detection. The palm-detection code was calling get_direction
on non normalized coordinates, this commits changes the code to normalize
the coordinates first. This is the right thing to do as calling get_direction
on non normalized coordinates may result in a wrong direction getting returned
when the x and y resolution of the touchpad are not identical.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a normalized_length helper function and use this where applicable,
just a minor cleanup.
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>
If the delta is 0, the distance is the number of units (within this ms). Delta
1 means velocity across 2 ms, etc.
Bonus: this doesn't return infinite speed anymore if we get more than one
event per ms. This can happen on any device approaching 1000Hz poll rate, but
definitely got triggered by the test suite.
Actual effect was limited, since we cap out acceleration at max_accel we just
hit this earlier and it stayed there.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
Converting to integer before the sqrt calculation can cause loss of
motion at low speed.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The acceleration curve consists of four parts, in ascii-art like this:
_____________
/
____/
/
/
where the x axis is the speed, y is the acceleration factor.
The first plateau is at the acceleration factor 1 (i.e. unaccelerated
movement), the second plateau is at the max acceleration factor. The threshold
in the code defines where and how long the plateau is.
This patch adjusts the curve based on a [-1, 1] range. For anything below 0,
the plateau is longer (i.e. accel kicks in at a higher speed), the second
incline is flatter (i.e. accel kicks in slower) and the max accel factor is
lower (i.e. maximum speed is slower). For anything above 0, the inverse is
true, acceleration kicks in earlier, harder and is faster in general. So the
default/min/max curves overlaid look something like this:
________ max
| _______ default
| / _____ min
_|_/_/
/
/
Note that there's a limit to what ascii art can do...
Note that there are additional tweaks we can introduce later, such as
decreaseing the unaccelerated speed of the device (i.e. lowering the first
plateau).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional changes, prep work for the config interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
To keep the implementation of a filter separate from the users of a filter.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We ran a userstudy, evaluating three different accel methods. Detailed results are
available at:
http://www.who-t.net/publications/hutterer2014_libinput_ptraccel_study.pdf
We found that there was little difference between the method we had in
libinput 0.6 and this three-line function. Users didn't really notice a
difference, but measured data suggests that it has slight advantages in some
use-cases.
The method proposed here is the one labeled "linear" in the paper, its profile
looks roughly like this:
_____________
/
____/
/
/
where the x axis is the speed, y is the acceleration factor.
The first plateau is at the acceleration factor 1 (i.e. unaccelerated
movement), the second plateau is at the max acceleration factor. The threshold
in the code defines where and how long the plateau is.
Differences to the previous accel function:
- both inclines are linear rather than curved
- the second incline is less steep than the current method
From a maintainer's point-of-view, this function is significantly easier to
understand and manipulate than the previous one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Makes it possible to use from the touchpad code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
In an attempt to bring method into the madness, normalize the touchpad deltas
to those of a USB mouse with 400 dpi. This way the data we're dealing with in
the acceleration code is of a known quantity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This just moves a decimal point around, at the expense of making the approach
harder to understand. The only time the const acceleration matters is when
applied to the velocity but it only matters in relation to the threshold which
is a fixed number.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
velocity is in unit/ms, the threshold is in units/ms. Once we divide
velocity/threshold, we're not in units/ms anymore but have a unitless factor.
Use a separate variable to avoid confusion.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Instead of always going from an accel of 0.0 to 1.0 between a velocity of
0.0 and 1.0, make the lead-in length of the curve depend on the threshold
setting, using half of the threshold for the lead-in.
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>
There was an error in the value passed to the second calc_penumbral_gradient
call causing a jump in the acceleration curve. This commit fixes 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>
Cleanup the code a bit, and make sure accel is at least 1.0 .
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>
I doubt this does what we think it does. It doesn't soften the delta changes,
rather it introduces bumps in the smooth processing of the changes.
abs(delta) below 1.0 is untouched, and abs(delta) beyond 3 or 4 isn't
noticable much. But in the slow range around the 1/-1 mark there is a bump.
For example, if our last_delta is 1.0 and delta is 1.1, the "softened"
delta is set to 0.6. That is stored as last delta, so an input sequence of:
0.8, 0.9, 1.0, 1.1, 1.2, 1.0, 0.8, 1.1
results in "softened" deltas that don't match the input:
0.8, 0.9, 1.0, 0.6, 0.7, 1.0, 0.8, 0.6
A better approach at smoothing this out would be to calculate the softened as:
current = current ± diff(last, current) * 0.5
or even weighted towards the new delta
current = current ± diff(last, current) * 0.25
In tests, this makes little difference. Dropping this function altogether is
sufficient to make the pointer pointer behave slightly better at low speeds
though the increase is small enough to attribute to confirmation bias.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For better consistency with filter_dispatch(). And move the things around to keep
the consumable API together.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
calculate_velocity() didn't skip pointer trackers far away in time when
calculating the initial velocity. This check was done later when
iterating the rest, so while at it, simplify the function by doing both
iterations in one single loop.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Short vectors alongside the x axis produced inverted directions.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This patch reimplements the simple smooth pointer acceleration profile
from X.org xserver. The algorithm is identical to the classic profile
with a non-zero pointer acceleration threshold.
When support for changable parameters is in place, to get a pointer
acceleration the same as the default classic profile of X.org a
polynomial acceleration profile should be used for when the threshold
parameter is zero.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We store timestamps in ms since system boot (CLOCK_MONOTONIC). This will wrap
after circa 50 days.
I've considered making our code wrapping safe, but that won't work. We also
use our internal timestamps to program timer-fds for timeouts. And we store
ms in a single integer but the kernel uses 2 integers, one for seconds and
one for usec/nanosec. So at 32 bits our ms containing integer will wrap
in 50 days, while the kernels seconds storing integer lasts a lot longer.
So when we wrap our ms timestamps, we will be programming the timer-fds
with a seconds value in the past.
So change all our internal timestamps to uint64_t to avoid the wrapping
when programming the timer-fds. Note that we move from 64-bit timestamps to
32-bit timestamps when calling the foo_notify_bar functions from
libinput-private.h. Having 64 bit timestamps has no use past this point,
since the wayland input protocol uses 32 bit timestamps (and clients will
have to deal with wrapping).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit introduces build script configuration for building a shared
library 'libinput.so' containing the evdev input device functionality
from weston.
evdev.c, evdev.h and evdev-touchpad.c are ported to not use the data
structures and API in weston and libwayland-server in order to minimize
dependencies.
The API of filter.c and filter.h are renamed to not include the
'weston_' prefix.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
AC_USE_SYSTEM_EXTENSIONS enables _XOPEN_SOURCE, _GNU_SOURCE and similar
macros to expose the largest extent of functionality supported by the
underlying system. This is required since these macros are often
limiting rather than merely additive, e.g. _XOPEN_SOURCE will actually
on some systems hide declarations which are not part of the X/Open spec.
Since this goes into config.h rather than the command line, ensure all
source is consistently including config.h before anything else,
including system libraries. This doesn't need to be guarded by a
HAVE_CONFIG_H ifdef, which was only ever a hangover from the X.Org
modular transition.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
[pq: rebased and converted more files]
Touchpad related code has been rewritten and moved to its own file
accessed by evdev via the dispatch interface.
The various functionality implemented are anti-jitter (don't jumping
around), smoother motions, touch detection, pointer acceleration and
some more.
Pointer acceleration is implemented as one generic part, and one touch
specific part (a profile).
Some ideas and magic numbers comes from xserver and
xf86-input-synaptics.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
