Patch to mouse accel code [and deceleration code]

[Craig Carey]

At 2004-11-11 15:18 -0500 Thursday, Keith Packard wrote:
>
>Around 14 o'clock on Nov 11, Jim Gettys wrote:
>
>> It would be better if the algorithm was coded to avoid floating point,
>> if it isn't too hard.
>
>This isn't a performance problem; at 100Hz, any system should be able to 
>execute a few software FP ops.  As the existing X server arc and line 
>drawing code requires FP, I don't see a problem with having the mouse code 
>use it as well.
>That said, code which can easily avoid FP is always nicer.
>


It seems that the patch does not remove the use of the C x86 float type.

The patch: http://freedesktop.org/bugzilla/attachment.cgi?id=1147

+             local->dxremaind = ((float)dx * (float)(device->ptrfeed->ctrl.num)) /
+                 (float)(device->ptrfeed->ctrl.den) + local->dxremaind;
+             valuator[0] = (int)local->dxremaind;
+             local->dxremaind = local->dxremaind - (float)valuator[0];


Maybe integers would be OK if 2**16 is returned when an old mouse
emitted one pulse when moving slowly.

       Fixing the mouse deceleration

The accelerating/decelerating code is here: procedure xf86PostMotionEvent ():

http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xfree86/common/xf86Xinput.c?rev=1.1.1.2.8.1&root=xorg&view=markup

Here is my explanation on how the X/XFree86 pointer ends up orbiting
around the final resting point.

(1) The dx-wise motion on the monitor VDU is proportional to

     (the accelerating number) * (the size of the pulse).  [equation 1]

The 2nd term is mainly zeros and ones, when the mouse is moving slowly.

Using a Logitech MX-500 does not improve things.

The accelerating/decelerating [diamond shaped] function should get
smoothed numbers. Currently it can get a "dx=1, dy=0" for these 2
cases:
 (1) a pulse every 1/4 second
 (2) a pulse every 3 seconds.

For a slow mouse, the input to the deceleration formula is too big,
because the time interval between pulses got bigger and the code
ignores the timing data.

To consider timing data, lead to bad jumpiness (when I tried that) since
numbers coming from the clock were too affected by slowdowns caused by
multitasking.

That patch probably won't lead to visible improvements. Windows 2000
has an enormously better mouse (and in Windows 2003 it got slower).

Also, the "abs(dx) + abs(dy)" creates a diamond shape where the mouse
is slower. There is a discontinuity at the edge thus the whole algorithm
needs ot be much changed. To fix that, did not produce a worthwhile
improvement (when I tried fixing that).

So, I ask this:

  Can there be a higher priority for the chain of subroutines that implement
  the acceleration / deceleration of the mouse ?. Task locking perhaps.

An alternative could be to timestamp the pulse before the operating system
has had an opportunity to slow down the pulse (and its dx,dy numbers).

How difficult would it be, to get a higher priority to the mouse
subroutines ?. What is the name of the procedure the would be modified if
a higher priority was added ?.

I note that XFree86 seems to have code that is about identical.

Future developers may prefer that 'real' numbers.




---                                                        Craig Carey