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
