The mouse deceleration algorithm. I got back to rewriting the code
in XFree86. I don't use XFree86 partly since I prefer to debug
other people's C bugs and port the software I want out to Windows.
Wow!, debugging Gcc bugs can be quite time consuming.
I implemented an averaging algorithm. Last time I wrote to xpert
I was claiming that most of the problem was with the absence of an
data averaging algorithm. At least for my Microsoft PS/2 mouse that
is outstanding in Windows 2000, maybe the problem is with the mouse
being unconfigured. (The mouse is part number 58264. It can handle
both PS/2 and Serial COM port protocols).
The algorithms is this: (dx,dy,time) was saved in an array 100 long.
All recent values up to 0.2 to 0.5 seconds was used to calculate an
average.
I suppose it is a bit better. I am not sure.
Having a big figure like 0.5 secs did not result in inertia which
was unexpected. I checked the result and it seemed to be correct.
In contrast, averaging using this can produce clearly visible
inertia and mouse trails:
dx[n] := f*dx[n] + (1-f)*dx[n-1]
I tried an algorithm like that to smooth the data that passed down
the ripple array and configuring it to reduce the smoothness of the
old dx,dy data seemed to result in a smoother mouse. Smoothing the
old data by averaging adjacent values in the ripple array seemed
to increase the jerkiness of the mouse and I am I am not sure but
maybe worsening the continuity of the data made the mouse
smoother when moved diagonally at a constant speed. To get that
properly considered could lead to a need to purchase many mice.
The improvement is still much too small and there seems to be only
one option left: XFree86 can't be sending the right instructions
to the Microsoft PS/2 mouse hardware. That forks the problem into
2 parts: averaging is still needed and the major problem seems to
to me to be with a failure to raise the hardware resolution.
In my test version I used a debugged version of the diamond shaped
deceleration algorithm. That algorithm needs to be replaced but
that can wait until the larger problems around it are improved a
lot. It has this style (but instead 2-D):
dx' := (dx if abs(dx)<threshhold else (N/D)*dx)
and I replaced he diamond with a square implementing this:
dx' := (dx if abs(dx)<threshhold else (N/D)*(dx-threshold*sign(dx)))
Possibly any old algorithm would do. It is that very algorithm that
newcomers might assume to be the cause of the problem. Microsoft
has a simple, dx & dy are independent, two piece linear algorithm
that uses 2 thresholds. It is documented under mouse_event in the
(DDK?) help available. I did not see info on the averaging algorithm.
To save us some time, maybe some reader could implement the hints
of this message and allow an analysis of the Windows mouse (but
this might be of small value if the major problem is a failure to
configure the hardware):
----------------------------------------------------------------------
At 2002\06\03 22:54 -0700 Monday, D. Holan wrote:
Subject: [ntdev] RE: Identifying PS/2 mouse
Date: Mon, 3 Jun 2002 22:54:41 -0700
From: "Doron Holan" <dor***@windows.microsoft.com>
To: "NT Developers Interest List" <[EMAIL PROTECTED]>
List-Subscribe: <mailto:[EMAIL PROTECTED]>
>If you are in windows 2000, insert yourself as a device upper
>filter into the ps/2 keyboard and mouse stacks. You can get to
>the data in 2 ways:
>1) via the service callback routine will give you the data
> as i8042prt has interpreted it
>2) you can insert an ISR filter and get at the raw data and
> do your own processing
----------------------------------------------------------------------
However it is not that obvious that reverse engineering that
algorithm would a satisfying big fraction of the needed improvement.
The "valuator[*]" variable could be made to be a real number.
That contains the numbers that are multiplied by the screen
width and height. It is unclear whether any user of XFree86 has
special code that can be switched in, to allow the user to escape
the problem.
Possibly the problem is not going to get fixed soon.
So maybe advice on which mice to buy is needed by us all. I suppose
that Kensington is much much too expensive over here in New Zealand
due to a high profit margin of the "yeah, they are mice" retail
chain outlet. Logitech was not getting commented on well by reviewers,
and Microsoft has now got the sample rate of one of its optical mice
running at a believable good rate, but maybe the buttons are not
OK for some potential buyers. Is there a mouse that permits an
escape from the problem of a "worse than Windows 2000 mouse" ?.
At worst, no one is escaping, in which some of the software would
need to be debugged.
Craig Carey
Auckland
New Zealand
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
