| Summary: | x11-wm/ratpoison interactive ( C-T: ) boxes disable keyboard | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Niklas Thörne <niklas.thorne> |
| Component: | Current packages | Assignee: | Desktop WM Team (OBSOLETE) <desktop-wm+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | estar |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 211520 | ||
| Bug Blocks: | |||
| Attachments: | test case | ||
|
Description
Niklas Thörne
2007-12-15 15:53:53 UTC
EDIT: Downgrading to xorg-server-1.4-r2 confirms that the bug was actually introduced in 1.4.0.90. Same here. Attaching to the Xorg process yields this backtrace:
#0 0x0809a4ee in EnqueueEvent (xE=0x82e1710, device=0x82f2e40, count=1)
at events.c:1070
#1 0x0809a89d in PlayReleasedEvents () at events.c:1161
#2 0x0809ab5c in ComputeFreezes () at events.c:1235
#3 0x0809b2ce in DeactivateKeyboardGrab (keybd=0x82de210) at events.c:1431
#4 0x080a1f5b in ProcUngrabKeyboard (client=0x8531a58) at events.c:4296
#5 0x0818c27f in XaceCatchDispatchProc (client=0x8531a58) at xace.c:281
#6 0x08089ba5 in Dispatch () at dispatch.c:502
#7 0x080728c0 in main (argc=9, argv=0xbfd58ee4, envp=0xbfd58f0c) at main.c:452
#4 is presumably (I didn’t really check this) in relation to an XUngrabKeyboard call in ratpoison’s src/input.c. (A directly subsequent call to XUnmapWindow to remove the input line window doesn’t happen.)
This is a bit inconvenient, particularly because it disables C-M-backspace and the VT switch keys along with everything else.
Created attachment 138986 [details]
test case
Here is a bit of code which mimics the relevant Xlib function calls from ratpoison. It grabs the keyboard, waits and ungrabs. If the user hits any keys while the keyboard is grabbed, ungrabbing hangs as above. This code only works (for me) if no windowmanager is running, i. e. it should be run e. g. as
X :1 & ( sleep 5 ; DISPLAY=:1 xterm -e ./a.out ) &
Is X supposed to behave like that with this code?
Hrm, not sure where to start. Is this with ratpoison 1.4.1 or 1.4.2? (In reply to comment #4) > Hrm, not sure where to start. > > Is this with ratpoison 1.4.1 or 1.4.2? > In my case it is ratpoison-1.4.1 I think that a fair guess is that this bug was introduced by the keyboard LED patch that was added to Xorg, as I think that I've read somewhere that the patch is somewhat 'ugly', and by the fact that this bug is a keyboard event related issue. I'm having this on my box too... Seems to be a xorg bug: cfr. http://bugs.freedesktop.org/show_bug.cgi?id=13511 ratpoison 1.4.3 solves this here Ratpoison 1.4.3 is now in the tree. Closing this bug fixed. |
