Created attachment 19754 [details]
xorg.conf

sounds like a stuck grab. can you narrow it down to a specific application that triggers this?

does the whole thing happen when you use nv instead of nvidia?

(In reply to comment #2)
> sounds like a stuck grab. can you narrow it down to a specific application that
> triggers this?

First I thought it is Gimp, but this morning it happened while surfing with Firefox.

> does the whole thing happen when you use nv instead of nvidia?

The second Monitor is not recognized by NV, so I cannot verify this.
But I will try adding a modeline this evening.

Can I provide more information? Or see more by myself?

Tobi 

Using NV to verify that it is a problem of nvidia or x11 in general does not work as my second board is only recognized as a 2mb board so I cannot get both screens working.

Unfortunealy I do not know which more informations I can provide.

Please ask if something is missing.


Thanks
Tobi

On Mon, Oct 20, 2008 at 03:10:43AM -0700, bugzilla-daemon@freedesktop.org wrote:
> (In reply to comment #2)
> > sounds like a stuck grab. can you narrow it down to a specific application that
> > triggers this?
> 
> First I thought it is Gimp, but this morning it happened while surfing with
> Firefox.

does the keyboard still work? If so, a minimal application like the following
should confirm the stuck grab:

Display *dpy = XOpenDisplay(NULL);
int rc = XGrabPointer(dpy, DefaultRootWindow(dpy), True, 0, GrabModeAsync,
                      GrabModeAsync, None, None, CurrentTime);
XCloseDisplay(dpy);

if (rc == AlreadyGrabbed)
    printf("already grabbed\n");
else 
    printf("%d\n", rc);


compile that up (with the necessary bells and whistles) and keep it handy to
run when the mouse gets stuck next time.

I have compiled it. 
But when the mouse "lock" appeared the program showed "0".
Actually it shows always only "0".

Is there something wrong?
The C Code: http://rafb.net/p/Gvsm9H33.html

and how i built it:
gcc -lX11 -Wall grab.c -o grab

Thanks
Tobi

> But when the mouse "lock" appeared the program showed "0".
> Actually it shows always only "0".

yeah, 0 means the grab was successful, so we at least can rule out that
something is hogging the mouse.

(In reply to comment #7)
> > But when the mouse "lock" appeared the program showed "0".
> > Actually it shows always only "0".
> 
> yeah, 0 means the grab was successful, so we at least can rule out that
> something is hogging the mouse.
> 

So what can I do to help you getting fix this bug?

Tobi

Hello,
now I am thinking it is a problem with my WM.
I used kwin when the problem first occurs.
But with fluxbox the mouse locks after 10secs.
With openbox it is working, but after some time I cannot use any WM related function. But the mouse is still working inside the windows.

Starting the WMs in a konsole/shell does not get me any new informations.

Any idea?
Thanks!

Tobi

I am experiencing the same bug here, using the same X version on Gentoo. Using KDE with KWin aswell.

There is no way I can trigger this bug, though. So I can't tell how to reproduce it. Sometimes it happens, sometimes it doesn't. There are days where I can use the Laptop without issues, then again there's a day it happens twice or three times. Already happened both in Dualhead and single LCD view. Using Xinerama.

Indeed a severe bug, because you have to log out/kill X to get the mouse working again and this is... not so nice ;).

However, all applications keep running as normal. I can even control them via the keyboard. It's just the mouse which appears to be dead. It can still be moved and I still see the cursor, but no control functions work anymore (no program reacts on buttons, scrollwheel or anything else).

Same problem here (Xinerama with NVidia binary driver from Ubuntu 8.10).

Running the grab program prints "0". The mouse moves, but the pointer doesn't change and clicks are ignored. The keyboard is fine. Window manager is Ion 3. This is a 32-bit dual-core system.

Also, there are a load of people with a similar-sounding problem here:

https://bugs.launchpad.net/debian/+source/rdesktop/+bug/55739

Running xkill turns the pointer into the skull-and-crossbones and then clicking somewhere turns it back to the pointer. But, nothing gets killed and the problem remains.

It's happening at the moment, and one odd thing about this time is that when I'm looking at the Vim window there is a region of the screen where the mouse pointer disappears if I move over it. This region covers part of Vim's window and also part of the other monitor. If I switch to another tab (using the keyboard) then this effect disappears, and the pointer is visible wherever the mouse is.

The problem usually corrects itself in somewhere between a few minutes and an hour.

What WM's are you using? 
Maybe it is a problem with WM's as I figured out that is happens more often when I change through them, e.g. from kwin to sawfish then to fluxbox.

Tobi

*** This bug has been marked as a duplicate of bug 18668 ***