Hutterer: X server pointer acceleration analysis [LWN.net]

For those who are curious about the rather complex way in which X server pointer acceleration works, Peter Hutterer has put together a four-part series on the topic: part 1, part 2, part 3, and part 4. "The input for the acceleration profile is a speed in mickeys, a threshold (in mickeys) and a max accel factor (unitless). Mickeys are a bit tricky. This means the acceleration is device-specific, the deltas for a mouse at 1000 dpi are 20% larger than the deltas for a mouse at 800 dpi (assuming same physical distance and speed)".

to post comments

Hutterer: X server pointer acceleration analysis

Posted May 11, 2018 2:59 UTC (Fri) by biergaizi (guest, #92498) [Link] (1 responses)

Impressive.

It's basically the work of 30 years by multiple generation of hackers on multiple generation of hardware, included 7 (!) curve profiles (e.g. linear, polynomial, power, smooth, etc), 15 (!) configurable parameters, and some confusing formulas. I guess it has been designed to smooth the pointer movement for everything that resembles as a mouse since 1980s...

Perfectly usable if user know how to configure. But now even developers cannot understand... And still, the code that almost no one can understand any longer still offers better pointer movement experience on many devices. Now thanks to Peter's valuable research, hopefully libinput developers would be able to provide us a better mouse point soon.

I guess software archaeology will become a serious area of research in the next 30 years, to rediscover useful algorithms and solutions found in forgotten legacy code.

Hutterer: X server pointer acceleration analysis

Posted May 13, 2018 3:44 UTC (Sun) by whot (subscriber, #50317) [Link]

> It's basically the work of 30 years by multiple generation of hackers on multiple generation of hardware

Not really. The current code is effectively unchanged since 2008 and prior to that the implementation was a simple one as 'dictated' by the X protocol specification. We had switchable Schemes too in 2008 (the next level up, each scheme may have multiple profiles), I think I removed that at some point so now we have only one scheme with the profiles because no-one ever even tried to implement a scheme and extra profiles.

> Perfectly usable if user know how to configure.

I'm going out on a limb here and say they don't 'know' how to configure. It's just trial and error until something works. And that's the reason it works better for some devices that fall out of the expected range: infinite configurability means that eventually you get something that works, but getting there is difficult and prevents many users from ever having a working device. You shouldn't need to know how xorg.conf snippets work to have your mouse work properly...

large multi-screen displays and wheels

Posted May 21, 2018 2:00 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link]

As we move to displays where one might have a 1 meter or larger desktop monitor, it would really help to have a "3rd gear" for the mouse, rather than the current system which is, at least under most DEs, just like 1st-gear and 2nd gear.
Also, mousewheel acceleration would help too...