Comments on acceleration cures

Um… what? Apple’s Lisa team did massive usability studies before deciding such details. And the article you link to doesn't say anything like your assertion (in my 2 minute skim), instead talking about the effects of inertia, etc. So I want to see your study that shows that a linear mouse response is best. Otherwise I call B.S., as in my personal experience the Mac mouse curve is vastly preferable to linear mouse response on Windows/Linux, and this is doubly true with a trackpad.

This is me reading deep into the comments about what people do or do not want in their hand/eye devices. Zero order algorithms are the term to use for linear, first order then refers to trackers that incorporate acceleration.  The changing acceleration coefficients  make it piece wise linear, just getting the terms straight a bi.

Playin separately with a Kalman filter, incomplete, framework had me thinking that the 64 bit machine does not run out of accuracy over he class of error terms in tracking, and maybe running a full Kalman is not a system drag at all.  This is one of those things where a simple linear filter with a correcting term gets me by for a while as I research the idea and others get some ideas.  I do not want to cast anything into stone here. But I think we will end up with a fixed point Kalman filter with a non linear coefficient on acceleration.  We are stuck with a non-linear alignment anyway when the cursor tracks off screen.

So I rig the code, as usual, a good enough tracker to get me by, leave that slot open for replacement as i derive the better method, or someone jumps in who has followed these hoops, or find find the best mouse tracker snippet in the world, or create that.
Another qote:

Here's what Chris Wickens and Justin Hollands have to say on the subject:

"Most control devices can be configured such that their displacement will produce either a constant displacement (zero order) or constant rate of movement (first order) of the cursor across the screen. (Only the light pen and touch screen must, by definition, be zero-order controllers, since the end of the pen or finger is the cursor.) However, it turns out that there are certain natural 'affinities' or 'compatibilities' between other control devices and either zero- or first-order system dynamics: Mice are best served by zero-order control dynamics, and joysticks are best served by first-order control dynamics.
"For the mouse, a zero-order control best captures the natural eye-hand coordination that is developed as a result of a lifetime of experience of pointing and reaching. The fact that the location of control movement (the mouse pad) is displaced from the location of visual (cursor) movement does not disrupt the naturalness of the link. For a zero-order mouse, it appears that the optimal gain is between one and three (Baber, 1997). That is, the cursor should travel between one and three times the distance traveled by the hand.
"In contrast, if a mouse were to generate first-order control, this not only abandons the natural eye-hand coordination, but would create a second problem, relating to the zero-velocity resting place. In pointing tasks, a zero-velocity (i.e., stationary) state is often the target point of movement. Hence, it is a desirable feature for the control system to automatically 'seek' that cautionary state. A mouse with first-order dynamics will not do that. The user must consciously move the mouse to the precise position on the pad where no motion occurs; and if there is a slight offset, the cursor will 'drift.'

OK,  have a picture of a complete and well written Kalman filter that gracefully degrades from first to zero order tracking.  The code be short, easy to swap functions in and  out.  Those codes exist, in snippet form today, and it can adapt, by parameter settings, to either mouse, joystick or touch pen. It has regime change mode, vi acceleration gestures, if need be, or the effect can e scaled.  I used to do this for a living, this is doable, we can make optional tracking methods to match optional devices in IO manager.  I have code to red the devices and from the /proc/input device descriptor file. Open the process up, make it easy to attach new devices, use the linux fd model, make it compatible with libev, and a complete gaming system. 
Then, dump X and take linux straight into the new game machines. A huge market. Consider taking the Rasberry, add an AMD co-proessor, leave our X, make it Wayland. With an add on IO package that all the game device makers knew could work on linux, a solid guarantee they have the shortest path IO manager in linux. Bingo, huge new market for linux. Huge opportunity for a kid who wants to do device drivers, with unlimited demand.