From owner-freebsd-hackers Sat Jun 1 1:13:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from drone5.qsi.net.nz (drone5-svc-skyt.qsi.net.nz [202.89.128.5]) by hub.freebsd.org (Postfix) with SMTP id 3129037B406 for ; Sat, 1 Jun 2002 01:13:47 -0700 (PDT) Received: (qmail 15466 invoked by uid 0); 1 Jun 2002 08:13:44 -0000 Received: from unknown (HELO COMPUTER.ijs.co.nz) ([202.89.142.113]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 1 Jun 2002 08:13:44 -0000 Message-Id: <5.1.1.2.2.20020601155903.038eec50@202.89.128.27> X-Sender: research@202.89.128.27 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Sat, 01 Jun 2002 20:11:48 +1200 To: freebsd-hackers@freebsd.org From: Craig Carey Subject: XFree86 BSD mouse inaccuracies; (xf86PostMotionEvent) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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