After some time using Xorg 6.8.2, the mouse pointer will reset itself to the
left side of the screen. Unless I move the pointer very slowly, it will keep
going back to the left edge of the screen. Occurs almost everytime I use X, but
appears to occur most often when GTK2 programs are open, particularly Mozilla
Firefox compiled to use GTK2 and XMMS. Also occurs most frequently and quickly
when using the Xfce desktop environment, which also uses GTK2, though it has
also happened when using Window Maker and FVWM. Has also happened regardless of
whether I use xdm, wdm, or no display manager.
Pointing devices used are an IBM keyboard with combination Trackpoint/touchpad
and a Logitech Marble mouse (which is actually a trackball), all using USB
connections. All are multiplexed using NetBSD's wsmouse driver.
Does this patch fixes the issue for you?
(It is from a PR in pkgsrc's GNATS regarding DragonFly support.)
I've witnessed the issue on my NetBSD/Xen station, though it would only happen
when under very high load. Suddenly the pointer would start sticking to the
left side (one time it stuck on the upper side). I believe this is the same
issue you're experiencing.
This is a regression from 6.8.1 to 6.8.2, the patch named on my URL is reverting
the code back to its 6.8.1 state and all the problems disappear. Of all people
who had this problem on DragonFly this patch fixed their issue.
I call it a showstopper for 6.8.3 or 6.9 depending on which is first.
Given how annoying this problem is I've bumped it from normal to blocker.
X is simply unworkable without the patch mentioned in comment #1 on NetBSD and
The same problem exists in OpenBSD-3.7. It has been fixed by making the kernel
correctly save/restore the FPU context during signal handlers.
There is now a regression test for that in OpenBSD:
moving to mouse component, but pretty sure at this point that it's a kernel issue.
I'm experiencing the same issue on linux 2.6.11 patched for XEN 2.0.7, xorg
I had same problem. I restarted X and now my mouse works fine.
I compiled and ran that OpenBSD fpsig.c (with no changes) on NetBSD/i386 2.0.2.
rainier:~/tmp$ gcc -o fpsig fpsig.c
rainier:~/tmp$ time ./fpsig
fpsig: 5700.000000 5146.000000
rainier:~/tmp$ time ./fpsig
fpsig: 5700.000000 5392.000000
ainier:~/tmp$ /usr/bin/time ./fpsig
9.09 real 9.03 user 0.00 sys
rainier:~/tmp$ /usr/bin/time ./fpsig
fpsig: 5700.000000 2260.000000
7.07 real 7.06 user 0.00 sys
rainier:~/tmp$ time ./fpsig
rainier:~/tmp$ time ./fpsig
What am I looking for? As you can see above sometimes it gives output and
sometimes it does not. Nine times I tested without using time and it never had
The fact that you get an output from time to time shows that there is a problem.
The program also exits with a non-zero status to show the failure.
This test program computes the same floating point value, using variables on the
stack both in the main code path and in a signal handler.
If signal handlers do correctly save/restore the FPU registers, the results are
unpredictable and will probably not be the same (and are printed). When no
corruption of the FPU, the 2 results are the same and nothing is printed (and
the exit status is 0).
You can replace 'while (count < 10)' with 'while (count < 1000)' (or bigger) to
run the test for a longer period to make it more "reliable".
In X I found out that running an (unaccelerated) glxgear while moving the mouse
around was a real efficient way to trigger the bug in 10-20 seconds. Glxgears
gets the X server to do lots of floating point computations (in Mesa).
Otherwise I could use X for whole days without seeing the bug.
Since the the FPU context save/restore has been fixed on OpenBSD/i386 no one
reported this bug again.
(In reply to comment #7)
> If signal handlers do correctly save/restore the FPU registers, the results are
oops: If signal handlers do *not* correctly ......
I had the problem again today. glxgears could be used within five seconds to
I am now using patch from
And now running glxgears with a lot of mouse movement for a few minutes doesn't
trigger the problem.
This was discussed some on the NetBSD' port-i386 list. I was told that NetBSD
3.0 (to be released soon) has changes so the fpsig test works fine there. (I am
using NetBSD 2.0.2 on this system.)
The problem in programs/Xserver/hw/xfree86/common/xf86Xinput.c seems to exist on
four different platforms (as shown in this bug report, but now fixed on newer
OpenBSD and newer NetBSD). Can this be redone to be portable? (No floating point
in signal handler?)
Created attachment 4548 [details] [review]
Dale Rahn found one additional cause that can trigger a similar problem.
When the input buffer gets full because the machine is too buzy, one byte in
the last event in the buffer is lost, causing corrupted events to be processed.
The attached patch fixes this additional case.
Note that hurd/hurd_mouse.c has the same bug.
I was having this issue under Gentoo Linux with Xorg 6.8.2, 6.9.0 and 7.0.
I took the changes in comment #9 and applied them successfully to the
xorg-server-1.0.1-r4 gentoo ebuild for 7.0. Recompiled and haven't had the
issue crop up in about 3 hours of use.
This is Linux 2.6.14 with Grsec and PaX patches on an x86. The issue hasn't
occured on the non-grsec/pax Gentoo builds I have with otherwise
same configurations (2.6.14 and Xorg 6.9/7.0) and hardware. Could this be
related to the similar protections grsec/pax provides that are also present in
OpenBSD? Just an uneducated guess based on circumstance.
Thanks for the patch.
*** Bug 5769 has been marked as a duplicate of this bug. ***
So, any ETA of merging this one into HEAD
I have this problem again with xorg-server MAIN on NetBSD/i386 3.99.20.
For NetBSD the patch in attachement 4548 is probably relevant. It was never
commited though. I've done it now.
Is there another way to cause this problem without glxgears?
This week my mouse has been stuck to left side twice -- but I can't
reproduce on my own -- even with glxgears on this system.
I am not using the latest xserver with latest fix (just used git to retrieve this).
I want to be able to test this before and after. Any ideas on how I can
reproduce the bug?
For the bug fixed by attachment 4548 [details] [review], getting the machine to swap heavily and
then moviing the mouse for a few seconds was enough to trigger the buffer full
On NetBSD -current, I am able to cause the cursor to be stuck on left side by
attempting to start up 100 firefox processes while using some Xorg built in April.
Using the Xorg with latest bsd_mouse.c fix (git and built on June 10), I can not
repeat the problem. It appears to be fixed for me. Thanks!
The problem happened to me again last night. First time since June 12.
(In reply to comment #19)
> The problem happened to me again last night. First time since June 12.
Not that i'm too deep into it, so just some blahblah: A fix (attachment 4548 [details] [review])
depending on just changing evalution order (or am I missing something?) is a big
fat sign there is something more subtle going on. The patch might be solely an
improvement, so proper synchronization might be the cure here. Assuming the
patch actually is an improvement.
Occurs in FC6 with xorg-x11-* packages updated to latest
NVidia drivers installed on AMD dual core with MS Wireless Natural KB and
Created attachment 11245 [details] [review]
proposed patch 2
From Otto Moerbeeck <email@example.com>:
A high resolution device that's moving fast can potentially generate
an int overflow, making dx*dx+dy*dy negative. Now pow(negative,
non-integer) yields NaN, so you loose. Use fp math to avoid that.
Committed to master: 12d27cf33c6d963eae77795c0d247175907162a5
Cherry-picked to server-1.4.
*** Bug 13010 has been marked as a duplicate of this bug. ***
*** Bug 13107 has been marked as a duplicate of this bug. ***
I have confirmed that on NetBSD current, IBM X31 thinkpad laptop, with NetBSD kernel of:
$ uname -a
NetBSD garlique.algebras.org 4.99.37 NetBSD 4.99.37 (GGM_ACPI) #0: Mon Nov 26 11:28:19 EST 2007 firstname.lastname@example.org:/data/Build/obj/usr/src/sys/arch/i386/compile/GGM_ACPI i386
and with modular xorg server 1.4, and xf86-input-mouse of 1.2.2 I *still* have this problem. Both of the patches above are demonstrably in the Xorg code, so, I think the comment that they are (at best) remediation, and some underlying problem still exists is true.
I have also confirmed the problem exists with openbsd-input-ws in this config.
I re-opened. But, I would acknowledge its arguably a corner-case, and may be confined to my situation. If somebody else says they see this, especially on another BSD, I'd tend to ask the bug be considered still open.
The fix was pushed in August as 12d27c.