From owner-freebsd-arch Mon Dec 31 23:10: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from drone2.qsi.net.nz (drone2-svc-skyt.qsi.net.nz [202.89.128.2]) by hub.freebsd.org (Postfix) with SMTP id 6ED9737B419 for ; Mon, 31 Dec 2001 23:09:57 -0800 (PST) Received: (qmail 52885 invoked by uid 0); 1 Jan 2002 07:09:55 -0000 Received: from unknown (HELO grandpa.ijs.co.nz) ([202.89.142.198]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 1 Jan 2002 07:09:55 -0000 Message-Id: <5.1.0.14.2.20020101180823.02dc8ac0@202.89.128.27> X-Sender: research@202.89.128.27 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Jan 2002 20:09:48 +1300 To: arch@freebsd.org From: Craig Carey Subject: RE: xfree4 by default?, mouse bug In-Reply-To: References: <20011231174113.O16101@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 01.12.31 15:43 -0800 Monday, John Baldwin wrote: > >On 31-Dec-01 Alfred Perlstein wrote: >> What is the proceedure one must follow to present xfree4 as the new >> default? It's been around for a long time and support a LOT more >> chipsets a lot better. Can we go ahead and just pull some switch >> or are there more sinister issues involved? > >The last time I and others brought this up to Jordan, the tentative plan was to >switch for 5.0. At this point in the game it is probably a bit late for 4.5, >however, if you want to head up an effort to get test port builds done after >the release with 4 as the default and get people to test it out then perhaps a >switch could be done for 4.6. > >-- FreeBSD maybe could make updates to version 4.x even when it does not make that version of XFree86 available. The following suggests that. (I doubt it is important to keep up to date since it is a big download and when taken from an XFree86 mirror, it seems to download OK and install OK. Maybe updates to resolve XFree86 bugs could be released if there is no fix from XFree86, KDE, or GNOME. The FreeBSD oscillating mouse that can't easily be positioned over a point XFree86 has a major bug in it. I presume the bug is going to be seen as rather significant by just about any user of FreeBSD. I don't know when a fix might appear. The bug causes this: when trying to move the mouse to a point, it strangely stops short of the desired final point. The user speeds up the mouse, and then strangely the mouse speeds itself up and there is an overshooting. The result is that the pointer oscillates around the final ending point until the user gives it full attention. This feedback problem goes away if the mouse is slowed down a lot. That seem bad and it is not better when it is known that some XFree86 coder accidentally a piecewise linear function to be discontinuous. I tried FreeBSD and quickly concluded the mouse is so badly done that the console mode of FreeBSD is a better environment than KDE's GUI system. The bug in the XFree86 subroutine named "xf86PostMotionEvent()" of file "xf86Xinput.c" (a pow(x,y)function is used when the xset threshold = 0): http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/common/xf86Xinput.c The XFree86 Hewlett Packard code seems have no similar problem (so the XFree86 developers could have copied from HP in the search for a remedy): http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/hp/input/x_hil.c To make it plainer, here is a plot of the function that processes the velocity data from the physical pointer device: Velocity used for the xf86PostMotionEvent() positioning the screen cursor | | / | / | / dx' = accel * dx | / | / | | | | | | | | | | | | | | | | | | | | | _| (case threshold not = 0) | __/ | __/ | __/ | __/ dx' = dx | __/ | / Distance from Endpoint, +----------------------- or the Physical Mouse Speed The two lines don't match up (before 1 Jan 2002). I sent in bug reports to KDE, GNOME, and XFree86, finable with the word "deceleration". Xfree86 seems to have no online bug management system. I don't use FreeBSD's GUI because of the bug, but now I have a way out which is to recompile XFree86. Anybody serious about FreeBSD would currently maybe want to recompile XFree86 v4, which is a ground for not making available binary releases of XFree86 version 4. Craig Carey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message