Binary package hint: compiz
When using Compiz it is possible for keys to get "stuck" down. A simple way for me to reproduce is to scroll wildly in firefox with the mouse wheel (or trackpad scroll edge) for a couple of seconds while holding down the "page down" button. After doing this the X server believes the "page down" key is permanently pressed, making other tasks obviously difficult. Repeating this procedure (holding down "page down" and scrolling madly) will generally unstick the key after a couple of tries, but once this has occurred the keyboard behaviour is still slightly strange: some modifier key combinations (alt-tab, super-tab for compiz, super-space for Gnome-Do) no longer work, and the key-repeat settings no longer apply - pressing a key produces exactly one character/event, no matter how long you hold it down for. However, Ctrl-left, Ctrl-backspace and the like still work.
This behaviour is not limited to the "page down" key, nor does it require madly mouse-scrolling - that just makes it dependably reproducible. It also happens to me with WoW under wine, where I often have the ',' key held down and use the mouse at the same time. It seems to require keyboard+mouse activity.
I'm filing this under Compiz because I can only reproduce this behaviour while Compiz is running. Try as I might, I can't reproduce under Metacity.
Some or all of bug #190934 may be the same as this. However, simply restarting X fixes this for me - I don't need to delete any settings, or kill gconf.
ProblemType: Bug
Architecture: amd64
Date: Fri Feb 22 13:09:11 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: nvidia
Package: compiz 1:0.7.0-0ubuntu3
PackageArchitecture: all
SourcePackage: compiz
Uname: Linux CowboyLaputopu 2.6.24-8-generic #1 SMP Thu Feb 14 20:13:27 UTC 2008 x86_64 GNU/Linux
(In reply to comment #0)
> When some window is opened by some grabbed key, grabbing all keys and they
> destroyed (like the window ratpoison opened uppon C-t :, or the window icewm
> shows when doing Alt-Tab), the xserver is caught in an endless loop within
> PlayReleasedEvents in dix/events.c.
interesting bug... tricky to track down.
The bug only occurs if Xkb triggers an autorepeat. In this case, XkbHandleActions overwrites dev->public. realInputProc with EnqueueEvent. When the device is unfrozen, the realInputProc is written back to the processInputProc and the whole thing craps out.
Here's a preliminary hack to fix it. It stops the loop occuring (tested with ratpoison) but I'm not sure what other implications it has. It most probably is not the correct solution.
diff --git a/include/xkbsrv.h b/include/xkbsrv.h >public. processInputPro c = proc; \ >processInputPr oc = \ >realInputProc = device- >public. realInputProc; \ >public. realInputProc = proc; \ >public. enqueueInputPro c) \ >public. realInputProc = proc; \ >unwrapProc = device->unwrapProc; \ >unwrapProc = unwrapproc;
index 167dbec..9f7f0d6 100644
--- a/include/xkbsrv.h
+++ b/include/xkbsrv.h
@@ -258,7 +258,8 @@ typedef struct
device-
oldprocs-
oldprocs-
- device-
+ if (proc != device-
+ device-
oldprocs-
device-