X stops receiving mouse clicks

[Emanuele Tamponi]

Hello,
First of all, my configuration is: KUbuntu 9.04, Xorg 1.6 (KUbuntu default)
with NVidia driver (KUbuntu default), configured with TwinView (Main: 1680x1050
Secondary: 1280x800 (Laptop Display)). Xorg uses HAL to find input devices
(AllowEmptyInput is set to true). I have a Wireless USB Keyboard+Mouse Set
(and obviously the Trackpad in the laptop, and the laptop keyboard). I use KDE
4.2.2 (KUbuntu default).

The problem: sometimes, and it happens most frequently when I leave the pc
alone for some hours, *some* or *all* the parts of my desktop stop receiving
mouse clicks. Most of the time, I can still click *only* on the Panel (but not
always).
Replication is difficult: it appears to happen completely at random. The only
solution currently is to restart X.
The keyboard keeps working flawlessy.
I tried to detach the wireless set, but this doesn't solve the problem.

Surfing the web, it looks like it may be related with Xinerama/TwinView. I
tried to disable both, and the problem still occours.

Thanks in advance,
Emanuele

[Peter Hutterer]

Post by Emanuele Tamponi
Hello,
First of all, my configuration is: KUbuntu 9.04, Xorg 1.6 (KUbuntu default)
with NVidia driver (KUbuntu default), configured with TwinView (Main: 1680x1050
Secondary: 1280x800 (Laptop Display)). Xorg uses HAL to find input devices
(AllowEmptyInput is set to true). I have a Wireless USB Keyboard+Mouse Set
(and obviously the Trackpad in the laptop, and the laptop keyboard). I use KDE
4.2.2 (KUbuntu default).
The problem: sometimes, and it happens most frequently when I leave the pc
alone for some hours, *some* or *all* the parts of my desktop stop receiving
mouse clicks. Most of the time, I can still click *only* on the Panel (but not
always).
Replication is difficult: it appears to happen completely at random. The only
solution currently is to restart X.
The keyboard keeps working flawlessy.
I tried to detach the wireless set, but this doesn't solve the problem.
Surfing the web, it looks like it may be related with Xinerama/TwinView. I
tried to disable both, and the problem still occours.

we've seen this in Fedora as well (that's on server 1.5) but not been able
yet to find the actual source of the bug. so far, it indicates a misbehaving
client, but we haven't managed to find that one either.
https://bugzilla.redhat.com/show_bug.cgi?id=488083

Any hints on how to reproduce this would be much appreciated.

Cheers,
Peter

[Emanuele Tamponi]

Post by Peter Hutterer
we've seen this in Fedora as well (that's on server 1.5) but not been able
yet to find the actual source of the bug. so far, it indicates a
misbehaving client, but we haven't managed to find that one either.
https://bugzilla.redhat.com/show_bug.cgi?id=488083
Any hints on how to reproduce this would be much appreciated.

Well, the problem is that I cannot reproduce it myself: it just happens at
random. I know, this makes it quite difficult to fix... so can you tell me if I
can log something useful to send to the ml? A program in the background for
example...

Anyway, I'll give you an information I discovered today and that may be
useful.

It looks like the mouse focus remains in a certain window, and that window
keeps it: this way, mouse clicks outside the window don't work. I'll explain
with an example.

Now, I'm writing this message with the KMail Composer. This window has the
focus: mouse input works in this window (menus, toolbars and even window
decoration). If I try to use the mouse in another window, it will not work.

I discovered kinda a workaround this problem too. If I right-click on the
window that has the focus, it "frees" the mouse until next click: so if I
click on some other window, it will receive mouse focus... and so on!

To explain with an example: now I'm writing this message with KMail Composer.
Mouse focus is on this window and cannot go outside it. But if I right click
on this window, and then on, for example, the firefox window I've opened in the
background, the firefox window will receive the mouse input.

So it looks like it's a problem of mouse focus and of windows keeping mouse
focus even if they shouldn't. This may be related to X, to the Window Manager,
or eventually on the Toolkit.

I exclude the toolkit because it happens on both Qt-based and GTK-based
application... I'll try to install compiz or some other window manager and
replace KWin, I'll let you know if the problem goes away.

If not, it's a problem related to X.

Cheers,
Emanuele

[Emanuele Tamponi]

Post by Emanuele Tamponi
I exclude the toolkit because it happens on both Qt-based and GTK-based
application... I'll try to install compiz or some other window manager and
replace KWin, I'll let you know if the problem goes away.

Tried with wm2, same problem.

So it really looks related to X. Any hint?

Emanuele

[walter harms]

maybe you can reproduce that with xev ?
does ist happen with other inputs devices also ? keyboard ?

re,
wh

Post by Emanuele Tamponi

Post by Emanuele Tamponi
I exclude the toolkit because it happens on both Qt-based and GTK-based
application... I'll try to install compiz or some other window manager and
replace KWin, I'll let you know if the problem goes away.

Tried with wm2, same problem.
So it really looks related to X. Any hint?
Emanuele
_______________________________________________
xorg mailing list
http://lists.freedesktop.org/mailman/listinfo/xorg

[walter harms]

Post by Emanuele Tamponi

Post by walter harms
maybe you can reproduce that with xev ?
does ist happen with other inputs devices also ? keyboard ?

I'll try with xev.
Every mouse device stops working: wireless mouse and builtin trackpad.

sounds like a strange bug in the subssystem.
This is beyond my capabilities :(

re,
wh

[Peter Hutterer]

Post by walter harms

Post by Emanuele Tamponi

Post by walter harms
maybe you can reproduce that with xev ?
does ist happen with other inputs devices also ? keyboard ?

I'll try with xev.
Every mouse device stops working: wireless mouse and builtin trackpad.

sounds like a strange bug in the subssystem.
This is beyond my capabilities :(

no, actually. this is how input devices work. the physical devices are
abstracted away through the virtual core pointer. all events go through this
core pointer device, and if an application grabs it then events are no
longer sent to anyone else. same with the keyboard.
hence if you have a rogue grab, all devices seem to stop working.

Cheers,
Peter

[walter harms]

Post by Peter Hutterer

Post by walter harms

Post by Emanuele Tamponi

Post by walter harms
maybe you can reproduce that with xev ?
does ist happen with other inputs devices also ? keyboard ?

I'll try with xev.
Every mouse device stops working: wireless mouse and builtin trackpad.

sounds like a strange bug in the subssystem.
This is beyond my capabilities :(

no, actually. this is how input devices work. the physical devices are
abstracted away through the virtual core pointer. all events go through this
core pointer device, and if an application grabs it then events are no
longer sent to anyone else. same with the keyboard.
hence if you have a rogue grab, all devices seem to stop working.

but only mouse events are missing, the keyboard seems to work fine
At least i would notice very fast if someone is eating my letters.

I think it is unlikely that a programm would only grap a mouse but
not the keyboard.

re,
wh

[Marius Gedminas]

Post by walter harms

Post by Peter Hutterer
no, actually. this is how input devices work. the physical devices are
abstracted away through the virtual core pointer. all events go through this
core pointer device, and if an application grabs it then events are no
longer sent to anyone else. same with the keyboard.
hence if you have a rogue grab, all devices seem to stop working.

but only mouse events are missing, the keyboard seems to work fine
At least i would notice very fast if someone is eating my letters.
I think it is unlikely that a programm would only grap a mouse but
not the keyboard.

To the extent of my understanding it's the usual thing in X land:
applications (or, rather, toolkits) implement things like popup menus
and drag-and-drop by grabbing only the mouse, while other applications
(e.g. SSH/GPG password dialogs) grab only the keyboard.

Marius Gedminas

[Marius Gedminas]

Post by Peter Hutterer
no, actually. this is how input devices work. the physical devices are
abstracted away through the virtual core pointer. all events go through this
core pointer device, and if an application grabs it then events are no
longer sent to anyone else. same with the keyboard.
hence if you have a rogue grab, all devices seem to stop working.

Are there any debugging facilities for finding out which X client has
the grab?

I once spent an hour killing all processes one by one until I found the
one responsible (gnome-settings-daemon):
http://mg.pov.lt/blog/xorg-snafu.html

Marius Gedminas

[Peter Hutterer]

Post by Marius Gedminas

Post by Peter Hutterer
no, actually. this is how input devices work. the physical devices are
abstracted away through the virtual core pointer. all events go through this
core pointer device, and if an application grabs it then events are no
longer sent to anyone else. same with the keyboard.
hence if you have a rogue grab, all devices seem to stop working.

Are there any debugging facilities for finding out which X client has
the grab?
I once spent an hour killing all processes one by one until I found the
http://mg.pov.lt/blog/xorg-snafu.html

if you have a second machine you can ssh+gdb in and look at
CLIENT_BITS(inputInfo.pointer->deviceGrab.grab->resource). this should give
you the client mask for the grab, and with xwininfo -root -children -all you
can then match that up with a running client (that's from memory, no
guarantees)

Cheers,
Peter

[Marius Gedminas]

Post by Peter Hutterer

Post by Marius Gedminas

Post by Peter Hutterer
no, actually. this is how input devices work. the physical devices are
abstracted away through the virtual core pointer. all events go through this
core pointer device, and if an application grabs it then events are no
longer sent to anyone else. same with the keyboard.
hence if you have a rogue grab, all devices seem to stop working.

Are there any debugging facilities for finding out which X client has
the grab?
I once spent an hour killing all processes one by one until I found the
http://mg.pov.lt/blog/xorg-snafu.html

if you have a second machine you can ssh+gdb in and look at
CLIENT_BITS(inputInfo.pointer->deviceGrab.grab->resource). this should give
you the client mask for the grab, and with xwininfo -root -children -all you
can then match that up with a running client (that's from memory, no
guarantees)

Thank you, this is more or less what I wanted to know in case the bug
strikes again (probably unlikely).

Marius Gedminas

[Marius Gedminas]

Post by Marius Gedminas

Post by Peter Hutterer

Post by Marius Gedminas
Are there any debugging facilities for finding out which X client has
the grab?
I once spent an hour killing all processes one by one until I found the
http://mg.pov.lt/blog/xorg-snafu.html

if you have a second machine you can ssh+gdb in and look at
CLIENT_BITS(inputInfo.pointer->deviceGrab.grab->resource). this should give
you the client mask for the grab, and with xwininfo -root -children -all you
can then match that up with a running client (that's from memory, no
guarantees)

Thank you, this is more or less what I wanted to know in case the bug
strikes again (probably unlikely).

The Bug took over a coworker's machine. After killing a couple of
processes at random and failing to find the one that had the mouse grab,
I installed Ubuntu's debug packages and ran

sudo gdb `which Xorg` `pidof X`
(gdb) printf "%x", inputInfo.pointer->deviceGrab.grab->resource

(gdb doesn't know about CLIENT_BITS).

I got something like 0x2600000, and found a bunch of resources belonging
to xchat-gnome that had IDs of the form 0x260xxxx in xwininfo output.

Unfortunately, killing xchat-gnome did not release the grab --- instead,
reconnecting with gdb I got a different resource ID (one belonging to
Skype). Killing Skype repeated the story: different resource ID
(Tomboy this time). I gave up and told my coworker to restart X.

Marius Gedminas

[Peter Hutterer]

Post by Marius Gedminas

Post by Marius Gedminas

Post by Peter Hutterer

Post by Marius Gedminas
Are there any debugging facilities for finding out which X client has
the grab?
I once spent an hour killing all processes one by one until I found the
http://mg.pov.lt/blog/xorg-snafu.html

if you have a second machine you can ssh+gdb in and look at
CLIENT_BITS(inputInfo.pointer->deviceGrab.grab->resource). this should give
you the client mask for the grab, and with xwininfo -root -children -all you
can then match that up with a running client (that's from memory, no
guarantees)

Thank you, this is more or less what I wanted to know in case the bug
strikes again (probably unlikely).

The Bug took over a coworker's machine. After killing a couple of
processes at random and failing to find the one that had the mouse grab,
I installed Ubuntu's debug packages and ran
sudo gdb `which Xorg` `pidof X`
(gdb) printf "%x", inputInfo.pointer->deviceGrab.grab->resource
(gdb doesn't know about CLIENT_BITS).
I got something like 0x2600000, and found a bunch of resources belonging
to xchat-gnome that had IDs of the form 0x260xxxx in xwininfo output.
Unfortunately, killing xchat-gnome did not release the grab --- instead,
reconnecting with gdb I got a different resource ID (one belonging to
Skype). Killing Skype repeated the story: different resource ID
(Tomboy this time). I gave up and told my coworker to restart X.

fwiw, we've had fun with a bug like this on a fedora 10 box and the culprit
was metacity. so far, we don't know whether it's metacity misbehaving or the
server dropping a ungrab request.

btw. the resource ID debugging works for active grabs, for passive grabs
it's a bit more complicated.

Cheers,
Peter

[Emanuele Tamponi]

Post by walter harms
maybe you can reproduce that with xev ?
does ist happen with other inputs devices also ? keyboard ?

I'll try with xev.
Every mouse device stops working: wireless mouse and builtin trackpad.

Emanuele

[Emanuele Tamponi]

Post by walter harms
maybe you can reproduce that with xev ?
does ist happen with other inputs devices also ? keyboard ?

I've attached it
I'll try with xev.
Every mouse device stops working: wireless mouse and builtin trackpad.

Sorry, what do you want from xev? Console output?

Please see it at http://www.valinor.it/xev_output (I cannot attach it because
the attach-file popup doesn't get the focus :P)

As you see, even after mouse leave event, the focus is kept by xev!

Emanuele