[ANNOUNCE] predictable pointer acceleration

[Daniel Stone]

Hi,

On Thu, Aug 14, 2008 at 02:22:45PM +0200, Simon Thum wrote:
> predictable pointer acceleration in X has arrived. Enjoy!

Awesome! Thanks. :)

> '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.

If it's fine with Peter, it's definitely fine with me.

>    * 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.

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.

>    * 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?

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.

>   * 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.

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.

>    * 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?

Yeah, I've been meaning to add timestamp support at one point, since we
also need it to do sensible key repeating.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20080814/fdfe4e20/attachment.pgp>