Bug 194703 – xfwm4 hangs X with gtk 2.11+ - mouse and keyboard no more work

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description Daniele C. 2007-10-04 13:10:41 UTC]

==My build==
I have recently done an 'emerge --sync' and then updated everything. I switched from kernel 2.6.22-r5 to 2.6.22-r8.
After an 'emerge --update --deep world' I also emerged xorg-server and several xf86 packages.

==Previous bugs still here==
The reason for which I updated Gentoo is because I had troubles with the mouse and the keyboard, but they are still here - coupled with worse side-effects (or maybe totally different bug(s)).
I use i8042.nomux=1 as kernel parameter because I would otherwise get ps2mouse.c bad sync messages (also got with r5); the keyboard issue (regarding the key release event not being caught and some atkbd.c messages in dmesg about unbound key codes) was possibly also related to the i8042 multiplexing, and is still present.
You can ask me more about this - if necessary; I thought it were relevant to the situation because those previous bugs also affect the same devices (from the user's point of view). See also "Logs" here below.

==The problem==
This bug report is about X dropping mouse and keyboard input (hence the previous note about other issues).
I start X (I am using XFCE4) and after making a tooltip pop up and then another one (possibly together, for example moving the mouse and clicking over the taskbar buttons of active processes) X starts hanging.
I realize that the situation is compromised because the tooltip never disappears. If I click on the taskbar button of a window, the window never comes up. At this point I can still use the keyboard and use Ctrl+Alt+Fn to switch back to the shell. Now if I click on another taskbar button or anyway not on the active window, the mouse input is dropped (e.g. the mouse moves but no click or hovering will ever be caught). Using the keyboard I can still work on the active window, but if I use Alt+Tab to switch to another window, the keyboard input is dropped too. Seems like the active window is getting all the keyboard input, while the other window (the taskbar button areas for example) compromised the mouse input.
When mouse input or keyboard input are no more received by any X window, I can't ever switch back to the shell - I could (sometimes) when HAL daemon was not running. At this point, I can only connect via ssh and run 'killall X' to get back control of my laptop. There's to say that the other windows, like the digital watch for example, keep working as usual and there is no process using 100% of CPU.

==Reproducibility and tests==
I had a wrong path for Xorg modules but the bug happened equally without any module being loaded. So it must be something about kernel vs X.
With the xf86-video-i810 v1.7.4 the bug happens more rarely if compared to xf86-video-i810 v2.1.0, but that's probably because the bug triggering condition is about the speed at which you can pop up two tooltip boxes at the same time: if you quickly hover two buttons of the taskbar, you will end up with the described situation. It is happening more rarely with i810 v1.7.4 possibly because the tooltip texts disappear more quickly - so no video card driver involved (I already said that without any module/driver loaded by xorg, it happens equally).
I have tried all sort of changes to xorg.conf parameters but neither DRI or GLX seem to matter.
Maybe the cause of everything is xfce4-panel, the process which creates the tooltips? How can I test if it is or not?

==Logs==
On the terminal from which I launched startx (Xorg.0.log), I can see that the last line is always "Synaptics DeviceOff called" when X is no more collecting my input. When I could switch to a terminal, the keyboard was working perfectly. It was X which was not catching the keypresses.

The following are possibly unrelated, if this new bug is not related to the previous bugs which I said to still be experiencing.

When I can still operate the keyboard, but if a key gets stuck, I have on dmesg:
atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known.

The above does not change wheter I am using i8042.nomux=1 or not.

When not using i8042.nomux=1, I have on dmesg:
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched.
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched.

Actually i8042.nomux=1 works around the mouse skipping bug that I would instead be experiencing too.

==Suppositions==
I am almost sure that we have here 2 different bugs, one regarding the mouse and one regarding the keyboard. As I told before, the resync issues are "solved" using i8042.nomux=1 - but still the mouse driver goes into a sort of infinite loops and no more sends the events to X.
On the keyboard side, I still get those stuck keys with relative atkbd.c message in dmesg, but if I press again the stuck key (it mostly happens with Ctrl or Alt) the key is back operational. So maybe that when the keyboard is no more operational on X, X got confused because of the weird input which it could read.

==Clearing out==
Sorry for the long report - but I wanted to be as much precise as possible; please tell me the tests that I should make in order to understand where the bug(s) are.

[Comment 1 Daniele C. 2007-10-04 17:38:10 UTC]

I have found that this bug is a duplicate of:

http://bugzilla.xfce.org/show_bug.cgi?id=3346

Please put the proposed patch on portage, it works perfecty on xfwm4 and fixes this nasty bug which I spent 5 days to individuate.

The proposed patch is a plain copy from http://bugzilla.xfce.org/attachment.cgi?id=1188

[Comment 2 Daniele C. 2007-10-04 17:39:10 UTC]

Created attachment 132569 [details, diff]
Patch which fixes the hangup of xfwm4 when using gtk+ v2.11 and above

[Comment 3 Samuli Suominen (RETIRED) 2007-10-04 17:57:00 UTC]

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

[Comment 4 Jakub Moc (RETIRED) 2007-10-05 09:30:33 UTC]

*** Bug 194781 has been marked as a duplicate of this bug. ***