filter: rename motion_filter_destroy to filter_destroy

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>
test: fix expected delta from relative motion

We send two delta events. One may get eaten or softened by the accel code but
our expectation should be that both may get through, so the length of the
expected vector is √((2dx)² + (2dy)²). That is the maximum length we expect
though for deltas ranged [-1, 1].

Deltas above the threshold would fail this test but we can fix that when
needed.

Pointer acceleration is subject to timing changes. When running tests in
valgrind pointer accel timeouts and tracker resets may happen so we can't
guarantee a specific acceleration length.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
filter: drop delta-softening

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>
accel_profile_smooth_simple: Cleanup

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>
accel_profile_smooth_simple: Fix jump in acceleration curve

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>
accel_profile_smooth_simple: Make 0.0-1.0 accel range depend on threshold

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>
filter: annotate the various variables we have with units

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
filter: use a separate variable for the final accel factor

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>
filter: drop constant acceleration

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>
touchpad: don't feed 0/0 deltas into the accel filters

The resolution-based scaling may result in deltas of 0. The accel code doesn't
handle 0 deltas too well. 0/0 deltas can't happen for EV_REL devices, so the
code just isn't designed for it.

Most notably, events with delta 0/0 have no direction. That messes up the
history-based velocity calculation which stops whenever the current vector's
direction changes from the one in the trackers.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
touchpad: normalize the touchpad resolution to 400dpi, not 10 units/mm

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>