Date: Sat, 01 Jun 2002 20:11:48 +1200 From: Craig Carey <research@ijs.co.nz> To: freebsd-hackers@freebsd.org Subject: XFree86 BSD mouse inaccuracies; (xf86PostMotionEvent) Message-ID: <5.1.1.2.2.20020601155903.038eec50@202.89.128.27>
next in thread | raw e-mail | index | archive | help
There is a problem with the mouse in X-Windows in FreeBSD. It
performs far worse than the Windows 2000 mouse. The problem is
due to software losing accuracy of real numbers, and a few bugs
in XFree86.
A way to show the loss of accuracy problem is to observe that
when there is an attempt to draw a circle, then the displayed
pointer path is more square in shape and it also may be unstable
in its position. Apparently XFree86 can't quite get the corner
of a circle looking good when it is receiving velocity values:
(0,1), (1,1), (1.0).
XFree86 has a deceleration implementing algorithm like this:
------------------------------------------------------
-- T = threshold, T>0. A=acceleration
> if 0 = threshold then
> if |dx| + |dy| < T then -- diamond region
> (dx, dy) := (1 * dx, 1 * dy)
> else
> (dx, dy) := (A * dx, A * dy) <-- #1
> end if
> else
> mult := 0.5 * ( (dx**2 + dy**2)**([A-1]/2) )
>* if (dx) {
>* local->dxremaind = mult * (float)dx + local->dxremaind;
>* valuator[0] = (int)local->dxremaind;
>* local->dxremaind = local->dxremaind - (float)valuator[0];
------------------------------------------------------
Online at: subroutine xf86PostMotionEvent:
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/common/xf86Xinput.c
That's text with the "#1" is from a bug report I sent to
XFree86 on 1 Jan 2002 that was neither acknowledged nor
acted upon. (They don't have a well running bug resolving
system).
Another fix that can be made in that code without causing a
problem, is to shift dx and dy towards 0 so that a micrometre
sized movement of the mouse does not produce a >15 pixel jump,
which is currently able to be observed. However if that fix
is made, it won't seem to eliminate a big enough fraction of
the bad behaviour (I tried doing that and it seems to be a
non-controversial improvement [I didn't report it to XFree86
at all]).
XFree86 code not only requires discretized input, but the line
"valuator[0] = (int)local->dxremaind;"
converts mouse pointer velocity information to a 2nd pair of
small integers before it is multiplied by the dimensions of the
final window. I never tracked that code down. It is code that is
partly destroying the credibility of BSD (and Linux) and the
motivation for it is unknown. They were not trying to avoid real
numbers things given that the there may be a call to a logarithm
function inside of the "raising to the power of" operation.
The emissions of a PS/2 mouse vary and stop if the mouse does not
move. That can be verified using this Windows program:
http://tscherwitschke.de/mouseratechecker.html
--
An example of adjusting the XFree86 configuration file:
---------------------------------------------
Section "InputDevice"
# Baudrate and SampleRate are only for some Logitech mice. In
# almost every case these lines should be omitted.
# Option "BaudRate" "9600"
# Option "SampleRate" "150"
---------------------------------------------
At least for one mouse, the sample rate (emission rate if PS/2)
can be increased. With PS/2 speeding up its output frequency,
then it might try to keep the data going into XFree86,
inaccurate. Possibly a *serial mouse* runs better in FreeBSD. A
serial mouse is getting out of date.
Since a fix might not get all mice out of the problem of bugs,
identifying the best mouse could be interesting. Some comments on
the Internet finger the Kensington Mouse-in-a-box mouse (PS/2) as
being one of the best (rather than Logitech or Microsoft).
http://home.att.net/~ascaris1/mouse.htm
http://www.ocia.net/reviews/mouseroundup/kensington.shtml
All my testing was done using a Microsoft PS/2 mouse in FreeBSD
and the main finding is that it seems very likely that XF
ree86
could maybe say that bulk of the problems fixable by altering
FreeBSD code. I presume GNOME and KDE ought blame Linux and
FreeBSD for having, but they have silly mouse configuration
pages forced upon them by XFree86s control of the meaning of
the two integers (holding small values): acceleration and
threshold.
An interesting bug that might be the last straw, is the
diamond shaped overshooting bug. The mouse can be observed to be
doing 2-3 orbits around the resting point. E.g. the "X" on the
top right of windows.
Someone else can investigate this. I don't intend to track
down the problem. What we could do with is data on both:
- the precision of data entering XFree86 and leaving FreeBSD;
and
- the (x,y) pointer position numbers that GUI programs inside
of KDE/GNOME, get to see.
There could instead be using 64 bit real numbers for input.
A message at the Slashdot website said that in Linux, the mouse
has always been "slower".
It is possible that a lot of people would use FreeBSD except
that there is a serious problem with the performance of its
mouse. If it came from a university, it was not partly designed
by any mathematics department.
Craig Carey
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.1.2.2.20020601155903.038eec50>