More on the mouse deceleration algorithm of XFree86. Previous comments missed the idea that the hardware developers were expecting a hybrid algorithm and XFree86 doesn't have one.
| For the fast PS/2 mouse, the information is much in the numbers, e.g. | (dx=2, dy=4). But for the slow PS/2 mouse, the numbers are mainly 0s and | 1s, and more of the information about the speed is in the delays between | mouse packets. XFree86 ignores (July 2003) the spacing (in time) between | mouse packets, and the no real to real function can behave properly when | the data is too discrete. | The solution relies upon a use of timing data, and that timing data is | significantly wrong if the data got queued up (which would tend to happen | when the CPU was loaded). | Possibly there is going to be a future need to have the mouse code get a higher priority thread. I put the (dx,dy,time) data into a buffer and then if it got bunched up, my algorithm spread out the points by shifting their times back into the past, so points were at least 1/80th of a second apart. That gave really bad results and it is easily the case that no algorithm would be good enough. I don't know so far. Perhaps a future XFree86 would raise the priority of the kernel (multitasking) thread(s) that handles mouse processing. (For the decelerating code, fast execution is only needed up to the moment when the time is taken note of.) Maybe someone else wants to do that. Also that bug KDE or XFree86, where "a drag with the left or Alt-ed right mouse button, does not cause a grab to actually occur", might be reduced somewhat easily by raising the priority of some thread. (The problem of 10-20 pixel jumps is easy to remove, but doing that produces a mouse that has a very slow speed (one pixel at a time) close to a clearly faster speed, and that problem worsens as the problem of huge jumps of an ultra-slow mouse, is reduced.) I have advanced mouse code, but it really did not improved the behaviour of the mouse pointer. I looked at it for a while and all I can think of about it, is that after timing data has got damaged and lost, a best algorithm can't recover from that. Maybe the mouse hardware resolutions is being set correctly. Also if thread priorities are much involved in the problem, then studying (measuring) the Windows mouse might find nothing that seems useful. Craig Carey _______________________________________________ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86