Replace pointer acceleration with a much simpler linear one

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>
filter: add a filter-private.h header file

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>
filter: move the threshold/accel into the filter struct

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>
filter: add a configurable speed interface

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
filter: adjust acceleration curve depending on speed

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>
touchpad: use the evdev device's filter struct

We don't need a separate filter struct, we can use the parent evdev device.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Add a pointer acceleration API

Only exposes one knob - speed, normalized to a [-1, 1] range with 0 being the
neutral "this is what we think is normal" speed. -1 and 1 reflect the
slowest/fastest reasonable speed on this device.

Note: with this API we commit to having any pointer accelerating as a true
gliding scale. We cannot map the [-1,1] range into a discrete set of steps
as we do not communicate to the caller whether a specific value has changed
the acceleration. Without that, a caller may assume that acceleration has
changed even when it is not visible to the user.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
evdev: hook into pointer acceleration config interface

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
touchpad: hook up pointer acceleration configuration

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
tools: keep a list of devices around for run-time changes

Hard-coded to 50 devices, because for a debugging tool that's plenty.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
tools: map KEY_UP/DOWN to pointer acceleration

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Add a configuration option for natural scrolling

Natural scrolling is simply inverted scrolling, but I decided to
use the Apple terminology simply because it's easier to google for.

Add the usual quartett of config options for has/set/get/get_default/, as a
boolean option rather than an enum for scroll mode to avoid name collusion
with the (currently in the works) edge scrolling.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
touchpad: hook up natural scrolling configuration

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
test: add tests for natural scrolling

2-finger scrolling only, we don't have anything else yet

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