[ANNOUNCE] predictable pointer acceleration

[Simon Thum]

Daniel Stone wrote:
> If it's fine with Peter, it's definitely fine with me.
Great!

>> 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.
> 
> Meh.  I'd suggest just making these the default when they merge.  If
> they're good, they're good; if they're not, they're not.  No use keeping
> the default as something we know to be suboptimal.
'when they merge'? It's in master since 2 weeks :)

The point here is that polynomial accel has an increased dependency on 
device characteristics. ATM I don't account properly for 
high-rate/high-res devices, so the acceleration varies with devices. May 
be negligible, may get unuseable, but It's definitely less a problem 
with the simple profile. So anyone with 'high-performance' devices, 
please give it a shot.

> Hmm, I don't know of anyone doing their own acceleration in the driver:
> that sounds a bit insane.  The only ones I really know of are tablets,
> which are absolute and thus unaccelerated anyway, so I don't really see
> why.
RTFM :)
There are a few cases: synaptics' acceleration being overdone; mouse.c 
has a equivalent setting to constant deceleration; and there is a 
sort-of optimization problem when devices are noisy: It's now better to 
do as much scaling as possible in dix, but  dix doesn't do error 
correction. So the driver knows best how much to scale down before 
passing to dix.

And I would like to account somewhat for the report rate (see above), 
which drivers have a better chance to know. Maybe HAL could jump in here.

>>   * The information maintained to make this possible, i.e. sub-pixel
>> position and velocity, is of some use further down the chain. For
> 
> Hmmmm.  I guess for relative devices, you could substitute the valuator
> data: synthesize fake x/y axes with scaling.  We could also define one
> axis to be used as velocity.
Axis for velocity is fine. Synthesizing an absolute axis - I don't know. 
Consumers would have to undo it, know which matches which etc.

> Yeah, I've been meaning to add timestamp support at one point, since we
> also need it to do sensible key repeating.
Fine. How's the input thread doing btw?

Cheers,

Simon