[ANNOUNCE] predictable pointer acceleration

[Simon Thum]

Hello list,

predictable pointer acceleration in X has arrived. Enjoy!

'Predictable' refers to one's ability to tell where the pointer will
move - even in the presence of acceleration. That wasn't really given
before.

The main features:
       * user-selectable profiles control pointer acceleration
       * adaptive and constant deceleration
       * acceleration becomes predictable
       * no overshoot when X blocks for a short time

To sum it up, it's all about useability and adaptability to a wide range 
of relative pointing devices.

I would like to propose it for inclusion in X server 1.6. If no-one
objects, I'll add it on the wiki.

More information is available here:
http://www.x.org/wiki/Development/Documentation/PointerAcceleration

It is intended to be a drop-in replacement, so if you didn't note it,
fine. Lookup the wiki to see how to benefit. Care has been taken to make 
the transition smooth, and the previous method is retained as an option 
to provide full compatibility. If any problems occurred, please let me know!

Acknowledgements go to to Peter Hutterer for his great support and 
generally getting it in shape, and to Daniel Stone who picked up on it 
initially. Thanks also to all the others who provided their insights on 
various issues.


For those who care (do you have a mouse?), here are some topics that
I think deserve some broader discussion:

    * By default, the benefits fall short of what's possible. Therefore
I propose changing the acceleration defaults so polynomial acceleration
comes to effect, with adaptive deceleration = 2. The first patch does 
that. Everyone on git master can test-drive the effect using 'xset m 2 
0' and setting adaptive deceleration (see the snippet below or in the 
wiki). Drawback: It's not too useable for people who switched back to 
the lightweight scheme.

    * I introduced a 'Driver API', which lets a device driver speak up
on some acceleration and scaling related issues. E.g. it could suppress
acceleration since it does its own, or provide some information to
improve results. The wiki has more details. The second attachment 
contains my proof-of-concept. So driver people: Is it reasonable? Would 
you use it?

   * The algorithm has numerous tweaks, and the defaults are pretty much
'my hardware + common sense'. Someone with more insight in hardware
variability should look at them.


Some points for future developments:

   * The information maintained to make this possible, i.e. sub-pixel
position and velocity, is of some use further down the chain. For
example, sub-pixel movement might be interesting in scroll bars, or a
widget might suppress extensive gfx effects if the velocity of the
pointer indicates that it's a spurious hit only. This would require
an input event rework and more or less dropping the lightweight scheme.

    * The code could further improve blocking cases using better
timestamps, such as evdev delivers. However, they can't be passed to DIX
at the moment. Moreover, Tiago's input thread could have a practically
equivalent effect. This would be strictly optional anyway since most
sources don't do timestamps. Opinions?

    * The velocity estimation (=reference for acceleration) is a separate
issue, but currently not implemented completely separate. I haven't seen
a realistic need to exchange it, but if anyone convinces me I might look 
into it. Reasons could be devices with speed sensors or devices which 
are unsuitable somehow for the present algorithm. Make your case.


Still reading? OK, here's a goodie: if you place the below snippet in 
your .fdi or put up an equivalent xorg.conf section, the velocity 
estimate will likely improve. When using a sane profile, i.e. not the 
simple default thing, this will further improve smoothness.

<match key="info.capabilities" contains="input.mouse">
   <merge key="input.x11_options.AdaptiveDeceleration" 
type="string">2</merge>
   <merge key="input.x11_options.FilterHalflife" type="string">5</merge>
   <merge key="input.x11_options.FilterChainLength" type="string">8</merge>
   <merge key="input.x11_options.VelocityCoupling" 
type="string">0.15</merge>
</match>

I'd make it the default but it is computationally more intensive, and 
simple profile users (the majority, I guess, since that was the only 
actually useable thing before) do not really benefit. If we were 
determined to get out the max, this would be the way to go however.

Have Fun!

- Simon Thum


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-dix-make-polynomial-pointer-acceleration-the-defaul.patch
URL: <http://lists.x.org/archives/xorg/attachments/20080814/1c33914a/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mouse-driver-to-dix.patch
URL: <http://lists.x.org/archives/xorg/attachments/20080814/1c33914a/attachment-0001.ksh>