[PATCH libinput 01/10] Replace pointer acceleration with a much simpler linear one

[Peter Hutterer]

On Fri, Sep 19, 2014 at 10:09:58AM +0100, Steven Newbury wrote:
> On Fri, 2014-09-19 at 15:44 +1000, Peter Hutterer wrote:
> > 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.
> > 
> Hi Peter,
> I'm going to read the report, but I would like to just state my 
> initial feeling on this.  Right now, in my experience*, the pointer 
> acceleration in libinput/weston is inferior** to that currently in 
> Xorg.  I find it relatively difficult to accurately position the 
> pointer in Weston while at the same time being able to comfortably 
> move the pointer over larger distances in a predictable manner.  The 
> Xorg code has been very well tuned over the last few years and IMHO is 
> at least as good as the Windows implementation (from a user point of 
> view).

The X server code has a bug where the size of the output screen influences
the acceleration on certain devices, touchpad devices included. Plug a
second monitor in and you'll see the touchpad speed go up. I've tried to fix
this a number of times, but stuff is so convoluted that I need to find a
spare week or two to fix this across synaptics and the server and update
both in lockstep.

I'd have to check the git logs too, but afaict the pointer accel code hasn't
seen any real updates since when it was introduced, with the exception of
some general cleanups and dropping of configurable schemes. So "well tuned"
is stretching the term, it just happens to work and you've had up to ~6
years of exposure to it. This is of course not discrediting your
experience, just remember that there is a learning curve associate with
pointer acceleration and you need some time to get used to how things work
before they become muscle memory.
 
> Any comparison between the libinput/weston implementations needs to be 
> base-lined against current Xorg and Windows/OSX!  I'm certainly not 
> opposed to improvements!

how? That's the main problem I had trying to analyse.
the study I ran has a couple of flaws in its design and mostly the
small data set but one of the abilities libinput provides us is comparable
data from multiple runs. That is almost impossible with X (see the screen
size issue for example), on top of the difficulty of getting this data out
of X in the first place.  Comparing to Windows/OS X is even more difficult
since we can't even assume the same events as baseline. I've looked at the
windows and OS X acceleration curves (see the Casiez et al. paper I
referenced in the study writeup for graphs of how they work) and tested them
locally but did not see a significant improvement.  If anything an OS X-like
curve made it even harder to use for some reason (note: subjective!).

Note that I'm not against further improvements down the road. I still think
that touchpads and mice need different accel curves (the linear one here is
not as easy to use on a touchpad as on my mouse here) but I don't have the
data to be sure. I could run the study again, modified a bit but right now
there are more pressing issues. The code is online however so if you want to
take it and continue with it I'm happy to help (or if you just find general
bugs that invalidate some of the results, though I guess my help won't be as
happy then ;)

There's also an argument that the delta smoothening that we do before
applying the accel curve may not be necessary. That needs separate
evaluation though and the day has only so many hours.

> Maybe my concerns are unfounded, I'll have a read of the report now... 
> :-)
> 
> * Using a Synaptics touchpad
> 
> ** For all I know it's the same code (haven't checked) but the 
> parameters must be different or there's a bug somewhere.

It should be mostly the same code (for relative devices anyway), but I'd
need to do a full audit to verify.

Cheers,
   Peter