[ANNOUNCE] predictable pointer acceleration
daniel at fooishbar.org
Thu Aug 14 06:35:13 PDT 2008
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
> 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
> * 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the xorg