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? http://www.in-nomine.org/~asmodai/pkgsrc/patch-bl (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 DragonFly.
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: <http://www.openbsd.org/cgi-bin/cvsweb.cgi/src/regress/sys/kern/signal/fpsig/>
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 6.8.2.
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. My results: rainier:~/tmp$ gcc -o fpsig fpsig.c rainier:~/tmp$ ./fpsig rainier:~/tmp$ time ./fpsig fpsig: 5700.000000 5146.000000 real 0m8.154s user 0m6.066s sys 0m0.007s rainier:~/tmp$ ./fpsig rainier:~/tmp$ time ./fpsig fpsig: 5700.000000 5392.000000 real 0m6.063s user 0m6.049s sys 0m0.005s 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$ ./fpsig rainier:~/tmp$ ./fpsig rainier:~/tmp$ time ./fpsig real 0m9.093s user 0m9.076s sys 0m0.012s rainier:~/tmp$ time ./fpsig real 0m9.091s user 0m9.058s sys 0m0.003s rainier:~/tmp$ 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 output.
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 repeat it. I am now using patch from http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/x11/xorg-libs/patches/patch-bl?rev=1.1&content-type=text/plain 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?) Thanks
Created attachment 4548 [details] [review] Proposed patch 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 condition.
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 Intellimouse 2.0
Created attachment 11245 [details] [review] proposed patch 2 From Otto Moerbeeck <otto@openbsd.org>: 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 ggm@garlique.algebras.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. cheers -George
The fix was pushed in August as 12d27c.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.