| Summary: | keyboard stops working in kde | ||
|---|---|---|---|
| Product: | [I don't know] kde | Reporter: | Divan Santana <divan> |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | akarikusanagi, amyodov, andresbajotierra, anselmolsm, auxsvr, a_kouz, b.m.kast, belaran, bjoern, brian, bs0001, bugs.kde.pistos, bugs, bugs, cberger, chealer, chris, corey_s, dbennett.ks, dsage152, esigra, f3lip3tkd, finex, fwilliamson, gera, geroxp, gokcen.eraslan, guysoft, ilya.minkov, jaba, jan.hnatek, jaroslaw.gorny, jesper, jezuch, jogojapan, johnbat26, juanvalino, julian, karlis.repsons, kde, kdebugs.20.orzelf, kdebugs, kevin.coonan, kwin-bugs-null, l.lunak, langec, laurent.rineau, llg, madgenius, mail, mannequinZOD, marcan, maw48, mcguire, me, mecirt, mhlavink, miketrml, mkyral, nico.kruber, null, oleg.atamanenko+kde, ompaul, oshcha, over1pixel, p2kj, rad.n, rdieter, richih-kde, roddibi, s.dremlyuzhenko, s.hs, salvalemany, superaphke, sven.burmeister, sysadmin, theevilgeek, vahram.mazlumyan, vasko, vincent, vl, vo.zaeb, yaroslav.sapozhnik, yasuyuki_izeki, zahl |
| Priority: | HI | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | lspci output | ||
|
Description
Divan Santana
2008-09-26 08:44:45 UTC
Af first you should try to update to a more recent KDE/X version. It seems a very strange issue anyway. Are you all using the same KDE/Xorg/nvidia versions? I am running kde 4.2.0 beta1 on kubuntu 8.10 with following nvidia drivers: ii nvidia-177-kernel-source 177.82-0ubuntu0.1 NVIDIA binary kernel module source ii nvidia-177-modaliases 177.82-0ubuntu0.1 Modaliases for the NVIDIA binary X.Org drive ii nvidia-glx-177 177.82-0ubuntu0.1 It still freezes randomly sometimes. I know of people running kde3 with non nvidia chips and it still happens to them. Anyway to troubleshoot this? Will try get them to vote for this bug. I can confirm this also happens to me, on two different machines (one running 64-bit, the other 32-bit; both running Ubuntu 8.10). Sometimes it can be fixed by mousing to the System Settings -> Accessibility panel, switching on all the accessibility options then switching them back off. In some cases, not even that fixes it. Also, these are always disabled when I start a session (every time I think to check, that is). Killing the session and restarting it fixes it, but obviously kills whatever I was working on, so that's not an ideal solution :( Same problem here, on 4.1.3 sometimes, on -svn so often i can't even use it. Additional detail: if I set up a screen after logging in (i.e. running "screen" from a terminal emulator started from the session) and detach it, I can recover later from this "keyboard stops working" problem by grabbing the text console (pressing Alt-F1 for instance), reattaching to the screen (which still has X session information in its environment), and running: $ killall kwin $ kwin & Returning to the graphical session (Alt-F7) presents a now-working environment with a working keyboard. It's necessary to go to the trouble of wrapping all this inside screen because if you try to start kwin from a regular console session, there isn't any useful X11 or KDE environment variables set up and kwin doesn't always figure out what to do. Because this restores keyboard functionality, I suspect it's a problem with kwin (or with some related component). Moved to kwin, maybe kwin devs could know if it is a known issue. to all experiencing the problem: are you using compositing? If yes does alt+shift+f12 still work if the problem occurs? Can you find any pattern that triggers the problem? E.g. using an effect, using alt+tab or using a fullscreen application and then triggering an effect like present windows? Yes, I am using compositing. Currently rendering is handled by OpenGL, though changing to XRender does not appear to impact this bug (positively or negatively). I will try Alt+Shift+F12 the next time this problem occurs. I have not been able to detect any reliable pattern for provoking this problem, though I have been trying to pay closer attention to what specific action I last took prior to experiencing the failure. I'll report what I can the next time this happens. (In reply to comment #7) > to all experiencing the problem: are you using compositing? If yes does > alt+shift+f12 still work if the problem occurs? Can you find any pattern that > triggers the problem? E.g. using an effect, using alt+tab or using a fullscreen > application and then triggering an effect like present windows? > I doubt this is caused from compositing. This definitely occurs even when compositing is switched off. Even on KDE 3.x.x with no compositing this bug still occurred and still does occur. Unfortunately I can't find any sequence of events of pattern that triggers this bug. Perhaps I can check an output of some file when the bug happens which can assist with this? This happens to me too. I'm using 4.2.0 on Gentoo and every now and then I can't input anything from keyboard, but I can switch to console (ctrl-alt-f1 ...). I also can start up a new user session on vt8. The mouse is still working. Un- and replugging the keyboard has no effect. I also upgraded to xorg server 7.4 and to nvidia drivers 180.27 -- also w/o any effect. W/ KDE <= 3.5.10 I never had this problem. I have no way to trigger/force that problem. *** This bug has been confirmed by popular vote. *** I have got this problem, too. It started to appear since I started to use KDE4, I never experienced this problem with KDE3. I don't have compositing enabled. Everything else (e.g. switching to another console via Alt+Fx) works as described before. I had the problem just a minute ago and having recently just read this thread: http://www.kde-forum.org/artikel/18339/kde4-looses-keyboard.html I started xev in konsole by copy-and-pasting the required letters into the window. After doing a few keystrokes the problem disappeared and I could use my keyboard again without restarting KDE (I'm typing this bug comment in the very same KDE session now). I also think the problem appeared this and the last time when I was pressing Alt-Tab for to switch to another application (I didn't switch, just saw a flicker, then the problem appeared) although I am not 100% sure. Here's the xev log, just in case that is of any interest:
Outer window is 0xea00001, inner window is 0xea00002
PropertyNotify event, serial 8, synthetic NO, window 0xea00001,
atom 0x27 (WM_NAME), time 42941477, state PropertyNewValue
PropertyNotify event, serial 9, synthetic NO, window 0xea00001,
atom 0x22 (WM_COMMAND), time 42941477, state PropertyNewValue
PropertyNotify event, serial 10, synthetic NO, window 0xea00001,
atom 0x28 (WM_NORMAL_HINTS), time 42941477, state PropertyNewValue
CreateNotify event, serial 11, synthetic NO, window 0xea00001,
parent 0xea00001, window 0xea00002, (10,10), width 50, height 50
border_width 4, override NO
PropertyNotify event, serial 12, synthetic NO, window 0xea00001,
atom 0x1bc (_KDE_NET_WM_USER_CREATION_TIME), time 42941477, state PropertyNewValue
PropertyNotify event, serial 14, synthetic NO, window 0xea00001,
atom 0x135 (WM_PROTOCOLS), time 42941478, state PropertyNewValue
MapNotify event, serial 15, synthetic NO, window 0xea00001,
event 0xea00001, window 0xea00002, override NO
ConfigureNotify event, serial 18, synthetic NO, window 0xea00001,
event 0xea00001, window 0xea00001, (0,0), width 178, height 178,
border_width 0, above 0xd400199, override NO
ReparentNotify event, serial 18, synthetic NO, window 0xea00001,
event 0xea00001, window 0xea00001, parent 0x1472274,
(0,0), override NO
PropertyNotify event, serial 18, synthetic NO, window 0xea00001,
atom 0x15d (_NET_WM_STATE), time 42941488, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0xea00001,
atom 0x1d3 (_NET_WM_DESKTOP), time 42941491, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0xea00001,
atom 0x1c1 (_NET_FRAME_EXTENTS), time 42941499, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0xea00001,
atom 0x177 (_KDE_NET_WM_FRAME_STRUT), time 42941499, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0xea00001,
atom 0x1d9 (_NET_WM_ALLOWED_ACTIONS), time 42941499, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0xea00001,
atom 0x15d (_NET_WM_STATE), time 42941504, state PropertyNewValue
MapNotify event, serial 18, synthetic NO, window 0xea00001,
event 0xea00001, window 0xea00001, override NO
VisibilityNotify event, serial 18, synthetic NO, window 0xea00001,
state VisibilityFullyObscured
PropertyNotify event, serial 18, synthetic NO, window 0xea00001,
atom 0x13a (WM_STATE), time 42941504, state PropertyNewValue
FocusIn event, serial 18, synthetic NO, window 0xea00001,
mode NotifyWhileGrabbed, detail NotifyNonlinear
KeymapNotify event, serial 18, synthetic NO, window 0x0,
keys: 4294967174 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ConfigureNotify event, serial 18, synthetic YES, window 0xea00001,
event 0xea00001, window 0xea00001, (1272,25), width 178, height 178,
border_width 0, above 0x0, override NO
VisibilityNotify event, serial 18, synthetic NO, window 0xea00001,
state VisibilityUnobscured
Expose event, serial 18, synthetic NO, window 0xea00001,
(0,0), width 178, height 10, count 3
Expose event, serial 18, synthetic NO, window 0xea00001,
(0,10), width 10, height 58, count 2
Expose event, serial 18, synthetic NO, window 0xea00001,
(68,10), width 110, height 58, count 1
Expose event, serial 18, synthetic NO, window 0xea00001,
(0,68), width 178, height 110, count 0
PropertyNotify event, serial 22, synthetic NO, window 0xea00001,
atom 0x1d6 (_NET_WM_ICON_GEOMETRY), time 42941636, state PropertyNewValue
FocusOut event, serial 31, synthetic NO, window 0xea00001,
mode NotifyWhileGrabbed, detail NotifyNonlinear
s
EnterNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42948116, (1,2), root:(1273,27),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus NO, state 0
KeymapNotify event, serial 31, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42948124, (4,2), root:(1276,27),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42948133, (6,2), root:(1278,27),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42948141, (9,2), root:(1281,27),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42948149, (12,2), root:(1284,27),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42948156, (14,2), root:(1286,27),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42948165, (16,1), root:(1288,26),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42948173, (18,0), root:(1290,25),
state 0x0, is_hint 0, same_screen YES
LeaveNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42948181, (20,-1), root:(1292,24),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus NO, state 0
FocusIn event, serial 31, synthetic NO, window 0xea00001,
mode NotifyNormal, detail NotifyNonlinear
KeymapNotify event, serial 31, synthetic NO, window 0x0,
keys: 4294967170 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
EnterNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42948989, (25,0), root:(1297,25),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus YES, state 0
KeymapNotify event, serial 31, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42948997, (27,6), root:(1299,31),
state 0x0, is_hint 0, same_screen YES
LeaveNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949005, (29,12), root:(1301,37),
mode NotifyNormal, detail NotifyInferior, same_screen YES,
focus YES, state 0
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0xea00002, time 42949013, (31,18), root:(1303,43),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0xea00002, time 42949021, (33,26), root:(1305,51),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0xea00002, time 42949029, (35,32), root:(1307,57),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0xea00002, time 42949038, (35,35), root:(1307,60),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0xea00002, time 42949045, (37,43), root:(1309,68),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0xea00002, time 42949053, (39,51), root:(1311,76),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0xea00002, time 42949061, (41,57), root:(1313,82),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0xea00002, time 42949069, (41,60), root:(1313,85),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0xea00002, time 42949077, (43,66), root:(1315,91),
state 0x0, is_hint 0, same_screen YES
EnterNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949085, (45,74), root:(1317,99),
mode NotifyNormal, detail NotifyInferior, same_screen YES,
focus YES, state 0
KeymapNotify event, serial 31, synthetic NO, window 0x0,
keys: 4294967170 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949097, (49,82), root:(1321,107),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949101, (51,90), root:(1323,115),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949109, (53,98), root:(1325,123),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949117, (55,106), root:(1327,131),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949125, (59,120), root:(1331,145),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949133, (61,128), root:(1333,153),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949149, (69,144), root:(1341,169),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949157, (70,146), root:(1342,171),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949165, (72,152), root:(1344,177),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949173, (72,153), root:(1344,178),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949181, (73,153), root:(1345,178),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949277, (73,152), root:(1345,177),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949297, (73,151), root:(1345,176),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949311, (73,150), root:(1345,175),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949317, (74,150), root:(1346,175),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949333, (74,149), root:(1346,174),
state 0x0, is_hint 0, same_screen YES
KeyPress event, serial 31, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949371, (74,149), root:(1346,174),
state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
XLookupString gives 1 bytes: (73) "s"
XmbLookupString gives 1 bytes: (73) "s"
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949388, (74,149), root:(1346,174),
state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
XLookupString gives 1 bytes: (73) "s"
XFilterEvent returns: False
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949397, (74,148), root:(1346,173),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949405, (74,147), root:(1346,172),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949422, (74,146), root:(1346,171),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949429, (74,145), root:(1346,170),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949437, (73,145), root:(1345,170),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949453, (73,144), root:(1345,169),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949469, (73,143), root:(1345,168),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949477, (72,143), root:(1344,168),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949485, (72,142), root:(1344,167),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949493, (72,141), root:(1344,166),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949509, (72,140), root:(1344,165),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949517, (71,140), root:(1343,165),
state 0x0, is_hint 0, same_screen YES
KeyPress event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949593, (71,140), root:(1343,165),
state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
XLookupString gives 1 bytes: (73) "s"
XmbLookupString gives 1 bytes: (73) "s"
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949814, (71,140), root:(1343,165),
state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
XLookupString gives 1 bytes: (73) "s"
XFilterEvent returns: False
KeyPress event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42949969, (71,140), root:(1343,165),
state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
XLookupString gives 1 bytes: (73) "s"
XmbLookupString gives 1 bytes: (73) "s"
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42950076, (71,140), root:(1343,165),
state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
XLookupString gives 1 bytes: (73) "s"
XFilterEvent returns: False
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42950173, (70,140), root:(1342,165),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42950181, (68,140), root:(1340,165),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42950189, (67,140), root:(1339,165),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42950197, (65,140), root:(1337,165),
state 0x0, is_hint 0, same_screen YES
KeyPress event, serial 34, synthetic NO, window 0xea00001,
root 0x82, subw 0x0, time 42950204, (65,140), root:(1337,165),
state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
XLookupString gives 1 bytes: (73) "s"
XmbLookupString gives 1 bytes: (73) "s"
XFilterEvent returns: False
I pressed "s" a few time and some other keys and clicked the mouse before that, so unfortunately I can't say when it started to work again exactly. Will try to pay more attention the next time it appears.
Ok, here is some more info regarding this bug. My colleague at work just experienced this problem. His system details: #lsb-release -a LSB Version: core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-2.0-ia32:core-3.0-ia32:core-3.1-ia32:graphics-2.0-noarch:graphics-3.0-noarch:graphics-3.1-noarch:graphics-2.0-ia32:graphics-3.0-ia32:graphics-3.1-ia32:desktop-3.1-noarch:desktop-3.1-ia32 Distributor ID: Ubuntu Description: Ubuntu 7.10 Release: 7.10 Codename: gutsy #kde-config -v Qt: 3.3.8b KDE: 3.5.10 kde-config: 1.0 #lspci|grep -i vga 01:00.0 VGA compatible controller: nVidia Corporation Quadro FX 570M (rev a1) I assume he's using the nvidia proprietary driver if he's using compiz. This time we weren't able to control+alt+f1/2/3 to switch to a tty. Also control+alt+backspace or capslock/numlock etc didn't work either. The mouse still worked fine though(as always) so we launched the kde virtual keyboard so we could try kill and restart kwin with it using the mouse. Strangely even the KDE virtual keyboard didn't type any keys. We then used the mouse and launched a terminal. From the terminal using letters on the screen we copied and pasted(using select and middle click) and managed to execute these commands: killall kwin This resulted in no kwin process and the reason is he is using KDE with compiz! We also tried doing a kwin --replace-wm we launched kwin but the keyboard was still frozen. Eventually we just restarted the laptop. So perhaps this isn't a kwin bug? Os its a separate bug to the one listed here. I've only ever heard of KDE users knowing about this bug, not gnome. And I've definitively experienced it myself on kde3 platform and kde4. Wish I could give more useful info. I can confirm this bug using KDE 4.2. The bug has been evident since KDE 4.1 for me and possibly prior to KDE 4, though I did not use KDE 4. KDE 4.2 was installed with a wipe of my drives and a new install of my operating system (Arch Linux). The symptom most often occurs while I'm using Kopete. After speaking to a person or people for awhile, the keyboard simply drops out while the mouse continues to function. As a result, I'm forced to log out/log in with KDM atleast [atleast] once a day due to the issue. I'm uncertain what I can do to help the cause, but I'll try to do about anything I can given some direction. As already stated, this is the worst bug KDE has for me, and by far the worst I've personally ever had out of any usable GUI. (In reply to comment #15) > though I did not use KDE 4. I guess you mean KDE 3. > The symptom most often occurs while I'm using Kopete. After speaking to a > person or people for awhile, the keyboard simply drops out while the mouse > continues to function. As a result, I'm forced to log out/log in with KDM > atleast [atleast] once a day due to the issue. Have you tried my suggestion to run "xev" when the problem occurs? The easiest way to run it is probably to create a shortcut to it on the desktop or somewhere like that. Also, what is the behaviour of your keyboard when the problem occurs? Does e.g. Ctrl-Alt-F1 still work and are you then able to type in the console? > > though I did not use KDE 4. > > I guess you mean KDE 3. My apologies - I should have been more specific. I intended to say KDE 4.0 here (as in) the initial release of the new platform. I did use KDE 3.5 from time to time in previous years with Mepis Linux, Kubuntu, and Sabayon though did not experience this issue. > > > The symptom most often occurs while I'm using Kopete. After speaking to a > > person or people for awhile, the keyboard simply drops out while the mouse > > continues to function. As a result, I'm forced to log out/log in with KDM > > atleast [atleast] once a day due to the issue. > > Have you tried my suggestion to run "xev" when the problem occurs? The easiest > way to run it is probably to create a shortcut to it on the desktop or > somewhere like that. > > Also, what is the behaviour of your keyboard when the problem occurs? Does e.g. > Ctrl-Alt-F1 still work and are you then able to type in the console? > I'll make a shortcut to "xev" for when the problem does occur and report back here the outcome either way. Concering Ctrl+Alt+F1, I have not tried much in regards to switching to the terminal or other hotkeys - I'll give that a go the next round of issues. Mostly this happens directly after pressing <alt>-<tab>. Switching to vt2 (strg-alt-f2) still works (as said), after `killall kwin ; kwin &` the KDE session accepts keyboard input again. But it's annoying as this could happen several time a day. The same problem was recently dicussed here: http://lists.kde.org/?l=kde-devel&m=123463012220073&w=2 I find it interesting that someone not using kwin had that problem. Perhaps the problem is another of the kdedglobalaccel symptoms when kded freezes. Typically we experienced the effect that it looked like the alt key was stuck. You could type but everything was interpreted as if the alt key was pressed too. If someone has the problem next time please do not kill kwin but kill kded. See if that makes keyboard work again. Mike (In reply to comment #19) > The same problem was recently dicussed here: > http://lists.kde.org/?l=kde-devel&m=123463012220073&w=2 Right, there are two issues which are discussed in the linked thread. One results in a black or greyed out screen and is resolved by disabling the logout desktop effect. That problem is not related to the bug described here. Some of the posts in this thread, discuss the bug described here. E.g. this post http://lists.kde.org/?l=kde-devel&m=123420972420136&w=2 where the poster describes a similar problem and suggest to execute kwin --replace to resolve it. The poster in this http://lists.kde.org/?l=kde-devel&m=123421096222621&w=2 post uses Nvidia graphics whereas the one here http://lists.kde.org/?l=kde-devel&m=123421096222621&w=2 uses Intel which supports my guess that the problem is not graphics driver related. Another poster (see http://lists.kde.org/?l=kde-devel&m=123428125523303&w=2) states: "I don't know if I'm experiencing the same or a different problem. From time to time, in both of my computers, my keyboard just stops working for a period of time. But mouse continues working, oddly enough. After some apparently random time keyboard gets back to life and it works again. It has happen to me in both laptops (Acer Aspire One being one of them). I use desktop effects in both too." ---> Seems like the keyboard comes back to life after some time. Has anyone tried waiting? > If someone has the problem next time please do not kill kwin but kill kded. See > if that makes keyboard work again. Thanks for the suggestion, will try that the next time the problem appears. It has been a few days since the last posting, and I wanted to give an update as to what has been ongoing. I await the keyboard to drop, but until this point things have held strong and as expected. I have rebooted once or twice since the last post. In terms of changes I have performed on my own system [ possibly ] relevant to this, I have changed from Kwin to Compiz full-time in the last two days. Whether or not this was the "solution" (quoted for obvious reasons) is simply too early to tell at this time. This happened to me again today, and I tried following the suggestion of killing kded instead of kwin. This had no effect, except to royally screw up the session (details below). When the keyboard started screwing up, this time it acted like I was holding down [ALT] even though I wasn't. Pressing/releasing it didn't help. To restore properly keyboard functionality, I had to drop to a text console ([ALT]-[F1]), log in, use screen to reattach to a shell I'd happened to have open (with all the usual X session environment variables intact) to try killing kded. It took a kill -9 to actually be rid of it. I restarted kded from the same shell, which didn't fix the problem (the keyboard was still wedged). Killing kwin and restarting it did work to restore functionality. In my case, it does appear to be kwin, not kded, causing the problem. Alright, I just had the problem again. This time it DEFINITELY happened when I pressed Alt-TAB to switch applications. I saw a flicker and then I couldn't use the keyboard again. After the experiences of the previous poster I didn't try to kill kded as I was in the middle of something and I didn't want crash the whole session. Instead I started xev again, and I was able to bring the keyboard back to life. Here is the output of xev (this time I did nothing except moving the mouse and pressing "g" a few times):
:~$ xev
Outer window is 0x12800001, inner window is 0x12800002
PropertyNotify event, serial 8, synthetic NO, window 0x12800001,
atom 0x27 (WM_NAME), time 107184117, state PropertyNewValue
PropertyNotify event, serial 9, synthetic NO, window 0x12800001,
atom 0x22 (WM_COMMAND), time 107184117, state PropertyNewValue
PropertyNotify event, serial 10, synthetic NO, window 0x12800001,
atom 0x28 (WM_NORMAL_HINTS), time 107184117, state PropertyNewValue
CreateNotify event, serial 11, synthetic NO, window 0x12800001,
parent 0x12800001, window 0x12800002, (10,10), width 50, height 50
border_width 4, override NO
PropertyNotify event, serial 12, synthetic NO, window 0x12800001,
atom 0x1bc (_KDE_NET_WM_USER_CREATION_TIME), time 107184117, state PropertyNewValue
PropertyNotify event, serial 14, synthetic NO, window 0x12800001,
atom 0x135 (WM_PROTOCOLS), time 107184118, state PropertyNewValue
MapNotify event, serial 15, synthetic NO, window 0x12800001,
event 0x12800001, window 0x12800002, override NO
ConfigureNotify event, serial 18, synthetic NO, window 0x12800001,
event 0x12800001, window 0x12800001, (0,0), width 178, height 178,
border_width 0, above 0x420014f, override NO
ReparentNotify event, serial 18, synthetic NO, window 0x12800001,
event 0x12800001, window 0x12800001, parent 0x14deb40,
(0,0), override NO
PropertyNotify event, serial 18, synthetic NO, window 0x12800001,
atom 0x15d (_NET_WM_STATE), time 107184154, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0x12800001,
atom 0x1d3 (_NET_WM_DESKTOP), time 107184155, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0x12800001,
atom 0x1c1 (_NET_FRAME_EXTENTS), time 107184163, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0x12800001,
atom 0x177 (_KDE_NET_WM_FRAME_STRUT), time 107184163, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0x12800001,
atom 0x1d9 (_NET_WM_ALLOWED_ACTIONS), time 107184163, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0x12800001,
atom 0x15d (_NET_WM_STATE), time 107184165, state PropertyNewValue
MapNotify event, serial 18, synthetic NO, window 0x12800001,
event 0x12800001, window 0x12800001, override NO
VisibilityNotify event, serial 18, synthetic NO, window 0x12800001,
state VisibilityFullyObscured
PropertyNotify event, serial 18, synthetic NO, window 0x12800001,
atom 0x13a (WM_STATE), time 107184165, state PropertyNewValue
FocusIn event, serial 18, synthetic NO, window 0x12800001,
mode NotifyWhileGrabbed, detail NotifyNonlinear
KeymapNotify event, serial 18, synthetic NO, window 0x0,
keys: 4294967170 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ConfigureNotify event, serial 18, synthetic YES, window 0x12800001,
event 0x12800001, window 0x12800001, (5,25), width 178, height 178,
border_width 0, above 0x0, override NO
VisibilityNotify event, serial 22, synthetic NO, window 0x12800001,
state VisibilityUnobscured
Expose event, serial 22, synthetic NO, window 0x12800001,
(0,0), width 178, height 10, count 3
Expose event, serial 22, synthetic NO, window 0x12800001,
(0,10), width 10, height 58, count 2
Expose event, serial 22, synthetic NO, window 0x12800001,
(68,10), width 110, height 58, count 1
Expose event, serial 22, synthetic NO, window 0x12800001,
(0,68), width 178, height 110, count 0
PropertyNotify event, serial 22, synthetic NO, window 0x12800001,
atom 0x1d6 (_NET_WM_ICON_GEOMETRY), time 107184265, state PropertyNewValue
EnterNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107203676, (176,85), root:(181,110),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus YES, state 0
KeymapNotify event, serial 31, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107203685, (166,81), root:(171,106),
state 0x0, is_hint 0, same_screen YES
[... a lot of similar entries as I was moving the mouse in the xev-window .... ]
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107203764, (68,21), root:(73,46),
state 0x0, is_hint 0, same_screen YES
LeaveNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107203772, (62,19), root:(67,44),
mode NotifyNormal, detail NotifyInferior, same_screen YES,
focus YES, state 0
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x12800002, time 107203780, (61,18), root:(66,43),
state 0x0, is_hint 0, same_screen YES
[... similar entries as I was moving the mouse in the xev-window .... ]
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x12800002, time 107203964, (56,10), root:(61,35),
state 0x0, is_hint 0, same_screen YES
EnterNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107203973, (56,9), root:(61,34),
mode NotifyNormal, detail NotifyInferior, same_screen YES,
focus YES, state 0
KeymapNotify event, serial 31, synthetic NO, window 0x0,
keys: 4294967170 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107203984, (56,7), root:(61,32),
state 0x0, is_hint 0, same_screen YES
[... similar entries as I was moving the mouse in the xev-window .... ]
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107204023, (54,0), root:(59,25),
state 0x0, is_hint 0, same_screen YES
LeaveNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107204028, (54,-2), root:(59,23),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus YES, state 0
EnterNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107204980, (55,0), root:(60,25),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus YES, state 0
KeymapNotify event, serial 31, synthetic NO, window 0x0,
keys: 4294967170 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107205001, (56,1), root:(61,26),
state 0x0, is_hint 0, same_screen YES
[... similar entries as I was moving the mouse in the xev-window .... ]
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107205061, (59,9), root:(64,34),
state 0x0, is_hint 0, same_screen YES
LeaveNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107205073, (59,10), root:(64,35),
mode NotifyNormal, detail NotifyInferior, same_screen YES,
focus YES, state 0
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x12800002, time 107205076, (60,11), root:(65,36),
state 0x0, is_hint 0, same_screen YES
[... a lot of similar entries as I was moving the mouse in the xev-window .... ]
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x12800002, time 107205132, (67,27), root:(72,52),
state 0x0, is_hint 0, same_screen YES
EnterNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107205142, (71,31), root:(76,56),
mode NotifyNormal, detail NotifyInferior, same_screen YES,
focus YES, state 0
KeymapNotify event, serial 31, synthetic NO, window 0x0,
keys: 4294967170 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107205152, (72,33), root:(77,58),
state 0x0, is_hint 0, same_screen YES
[... a lot of similar entries as I was moving the mouse in the xev-window .... ]
MotionNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107205487, (172,159), root:(177,184),
state 0x0, is_hint 0, same_screen YES
LeaveNotify event, serial 31, synthetic NO, window 0x12800001,
root 0x82, subw 0x0, time 107205492, (178,167), root:(183,192),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus YES, state 0
FocusOut event, serial 31, synthetic NO, window 0x12800001,
mode NotifyWhileGrabbed, detail NotifyNonlinear
gggg
[The last g's not necessarily mark the point where the keyboard started to work again, it's possible that it was already working before, I just put the focus back to konsole then]
Sorry, forgot to mention something: my keyboard did not behave like the ALT key was stuck. There was no reaction at all. Please don't forget to vote for this bug ;-) I get this problem from time to time - keyboard totally unresponsive (I haven't tried ctrl-alt-F1 etc, so don't know whether they work). I suspect that it may happen after holding the shift key down for longer than a normal keypress, but not long enough to activate the sticky keys confirmation dialogue. The fix is to use the mouse to go to System Settings -> Accessibility -> Modifier Keys, and first select Use Sticky Keys (followed by Apply) and then deselect Use Sticky Keys (plus Apply). For me, this fixes the keyboard every time. Note that I have all desktop effects switched off (I presume that compositing comes under desktop effects??). David: This problem occurs even when all accessibility features are disabled (as it is on my system). I don't have any accessibility features switched on either, but toggling the sticky keys setting always fixes my keyboard freezing. The first few times this happened (last year), toggling as you suggest sometimes helped, but sometimes didn't. Now, it has no effect. I'll continue trying it though when it crops up again (any fix is superior to restarting kwin, since doing so irritates just about everything running in the session :)). Ok this just happened to me again. Unfortunately I don't know what caused it. As most times control+alt+f2 control+alt+f1 etc worked and the mouse. I did the following: sudo killall -9 kded && kded from my konsole within KDE. Keyboard still frozen. sudo killall -9 kwin && kwin Keyboard still frozen strangely. Then I checked and saw kded4 was running and tried this: sudo killall -9 kded4 && kded4 and then keyboard starting working immediately and had a backlog of some of the previous key strokes I typed. My session was pretty messed up and acting funny after that so I restarted X and restarted session again. I did get a popup about Compositing not responding quick enough so it was disabled but I've never had that before previous times keyboard froze. O and before I did the killall stuff I went to systemsettings and did the accessibility stuff enabled and disabled it and it make no difference. I have turned mine off in the past to and still had keyboard freezes. I found out that resizing the window (in which keyboard stops working) helps for me, after resizing that window the keyboard works again (*without* any "kill kwin" or "kwin --replace"). Alright, this happened again as of 10 minutes ago, roughly 10:35pm CST. I am using Compiz (not Kwin) per Fusion Icon. The only thing to change on this system in the last four or five days (four or five days since I've had this issue) was a bleeding edge update to the current Arch Linux repos (pacman -Syu) as of 6:30pm, four hours ago, and a reboot shortly thereafter. Notable updates from "pacman -Syu" include: Compiz to 0.8.0, a kernel update, as well as some X whatnots that I can't quite remember (but are available via the Arch Linux package update listing on their website). When the malfunction occured, I was typing in Kopete once again. It was after I had sent a message (much as last time), and I was beginning to send a new one. Immediately, I began hitting random keys. I loaded xev. No single keypress of any key did anything, including Ctrl+Alt+F1 or Alt+F1-12 or Ctrl+Alt+F1-12 nor any other maneuver I could think of. Xev did not detect any keypress in the first minute of my using the program. I began noting, focusing on both Xev and (from time to time) the Kopete chat window I had open, keys would appear as long as I held them down for about two seconds. Any key whatsoever would type, but no Ctrl+Alt+F1, etc., pattern would respond to such a method. If I held down Ctrl+Alt+Del while focused on the desktop, the Logout, Shutdown, Reboot option would appear in KDE. I did not shut down and thus cancelled, continuing the test. Usable programs running at the time were: Audacious, GIMP, Kopete, Opera, and KDE's terminal. WINE had been running a few moments before this occured. With the mouse, I logged out from the start menu. KDM loaded fine and I was able to enter KDE once again with a working keyboard. On loading KDE, immediately Nepomuk suspended 'Stringi' or 'Stringl' or something to that effect - I didn't get a chance to read the message entirely. I decided to write this down while the process was occuring, thus to give a better perspective on what was ongoing. This is all I have, but if the issue occurs again I will try other things given some direction. And, roughly two hours later (12:45), the problem occured once again. I only had Kopete, Audacious, and Compiz active. (In reply to comment #32) > And, roughly two hours later (12:45), the problem occured once again. I only > had Kopete, Audacious, and Compiz active. Also, I would like to add - it's almost as if there is a buffer that fills to the brink of it's capacity. I'm doing a considerable amount of typing in Kopete, and I'm honestly beginning to wonder if, after so many characters, the buffer just fills to a point that it can't retain the information or doesn't delete the old character after the new character's input. (In reply to comment #33) > (In reply to comment #32) Another hour has passed full of Kopete chat and this has occured twice more. This four times in almost as many hours. Here is what has occured: I have been quite active in Kopete chatting to several friends. The third time the keyboard stopped working is when I accidently highlighted something in the chat window moving the mouse over some words (and accidently clicking the button). When I refocused the window to the chat portion (with the mouse), I could no longer chat. The fourth time is when I loaded Firefox expecting to come here and post concerning it just a moment after my relogin from KDM. I rebooted. What have I noticed? Since the first time of this occuring tonight, the message 'Suspending Stringl file indexing to preserve resources' has popped up in my systray. Since my reboot, I have killed the nepomukservices process in curiosity as to see what that would accomplish. If it accomplishes nothing, it's better to find out than to sit idly while the problem continues. The thing that Nepomuk suspended is called "Strigi". It's a desktop search engine that eats a lot of system resources, but I doubt that it's related to the keyboard. (In reply to comment #35) > The thing that Nepomuk suspended is called "Strigi". It's a desktop search > engine that eats a lot of system resources, but I doubt that it's related to > the keyboard. Respectfully, I don't care whether or not this is an issue that may or may not be related to the hangups. I'm attempting to utilize every method I know how to take care of this problem and to report what I'm doing as a result. This problem is a scary problem that, if I were in control of the primary message, would be marked as very severe and extremely dangerous to the KDE workspace. The timing of this issue pops up at any interval, and it's grasp on the system is headstrong and overbearing to the point of near reboot if not reboot. It's an embarrassment to the environment that needs to be fixed. I look forward to continuing to work with the KDE devs and those of us continuing to experience the issue regardless. I will post here if anything I've done thus far does not work, and I will update anyone here on the ongoings so that it may help them in their trials. Removing myself from CC list; this happens regularly enough for me now that I can't continue using KDE. I apologize that I can't be of more assistance in identifying the problem or suggesting a fix. (In reply to comment #29) > I did the following: > sudo killall -9 kded && kded from my konsole within KDE. > Keyboard still frozen. > sudo killall -9 kwin && kwin > Keyboard still frozen strangely. > Then I checked and saw kded4 was running and tried this: > sudo killall -9 kded4 && kded4 and then keyboard starting working immediately > and had a backlog of some of the previous key strokes I typed. This makes me think it's a kdedmodule that's acting up. Possibly KHotKeys? The list of running kded4 modules should be in System Settings -> Advanced -> Service Manager On seeing that KHotKeys was a suggestion, I disabled the process and removed it from startup. An hour and a half later (ten minutes ago), the problem reoccured. I was using Kopete again, chatting to a couple of friends for about an hour. While typing, it worked great. When the message was sent, as always, I could not start typing again without issue. Immediately, I found out from my previous method (my previous problem-stating post) the keyboard was usable *only* if you press a key for longer than a second or two for the echo to appear. If a terminal is open during this time period, you can (very slowly) type out anything necessary. "top" was running and visible at the time the problem occured. No process listed itself outside of the ordinary. From the terminal already open on the desktop, I (slowly) typed "kwin -replace". A message appeared several times: Xlib: extension "Generic Event Extension" missing on display ":0.0". The keyboard response was still not normal. On typing "compiz -replace", the same message appeared, again, several times. The keyboard response was still not normal. The only solution was to log out of KDE and return to KDM for normal keyboard usage. I have since rebooted. This is twice I have rebooted due to this issue in as many days since the update to the system from the Arch repos. (In reply to comment #39) > Xlib: extension "Generic Event Extension" missing on display ":0.0". This is a harmless warning message according to the Xorg developers. It's just like the XDamage "error" messages that KWin gives out, they mean nothing. (In reply to comment #40) > (In reply to comment #39) > > Xlib: extension "Generic Event Extension" missing on display ":0.0". > > This is a harmless warning message according to the Xorg developers. It's just > like the XDamage "error" messages that KWin gives out, they mean nothing. I understand. I'm reporting any and everything I possibly can in hopes that something can be done about this (and soon). If anyone has a suggestion concerning this problem, I would be more than happy to give it a trial. (In reply to comment #39) > Immediately, I found out from my previous method (my previous problem-stating > post) the keyboard was usable *only* if you press a key for longer than a > second or two for the echo to appear. If a terminal is open during this time > period, you can (very slowly) type out anything necessary. I just want to make sure that you really experience the problem which is described in this bug - from reading your previous comments I was not completely sure about that, as your experience sounds a little bit different from others (e.g. Ctrl-Alt-Fx not working, too and keys working with delay). Are you sure you are not experiencing the "slow keys" problem as described here (http://www.linuxquestions.org/questions/linux-hardware-18/strange-keyboard-problem-522956/): ---------------- snip It sounds like you've invoked the "slow keys" "accessibility" option. The pop-up window is displayed when you hold a (non-repeating) key down for "too long," and asks you if you want to use "slow keys." E.g., holding down the shift key for a ten seconds without typing anything. If you're using KDE, bring up the "Control Center," got to the "Regional & Accessibility" section, then look in the "Accessibility" subsection to change it. If you're using GNOME, look under System -> Preferences -> Accessibility -> Keyboard to change the setting. While I understand what you're suggesting, let me quickly put out that fire. No, this is not the 'slow keys' option nor does this issue have anything to do with it. To confirm: the option itself is disabled within the Accessibility settings, and the two times said window -has- popped up (only by pure accident on my part), I have made sure to select no each time. I can't stand "slow keys" nor it's respective popup, FYI, and per your message I've actually disabled it's notification. Make no mistake when I say this - if this were an issue so simple to take care of, I'd have already changed it. ;) I'm not a new user to KDE (or Gnome) by any stretch or length of the imagination. If you go back and read what I've stated concerning this (several times now), the issue described pops up whenever it feels like for no reason whatsoever on my part. (In reply to comment #43) > To confirm: the option itself is disabled within the Accessibility settings, > and the two times said window -has- popped up (only by pure accident on my > part), I have made sure to select no each time. I can't stand "slow keys" nor > it's respective popup, FYI, and per your message I've actually disabled it's > notification. > Make no mistake when I say this - if this were an issue so simple to take care > of, I'd have already changed it. ;) I'm not a new user to KDE (or Gnome) by any > stretch or length of the imagination. > Alright, I just wanted to rule out this possibility - at least we're now clear about that, too. I experciened the slow keys issue before (I activated it several times by accident) and I was not aware of this feature so it didn't come to my mind that this could be related to the accessibility options. But unfortunately the problem here is a different animal... Just tested, pressing a key for longer time doesn't help anything here, but as said above resizing the current focussed window (_not_ with the restore button in the title bar, but with the side border). After resizing just a few pixels keyboard is back working. (I don't know if it's related to that bug, but after the keyboard stops working for the first time ctrl-meta (show mouse pointer) doesn't work anymore) Had the problem twice today and I was able to re-activate the keyboard both times by resizing the window which was active when the problem appeared. Had to de-maximize it and then resized it through the side border. Equipment: Dell m1330, Kubuntu 8.10, KDE 4.1, nvidia 177 drivers, with dreadful broadcom drivers, to boot. Just experienced the same "keyboard disconnect" as the other posters (it's happened 3 or 4 times). Mouse works, everything is responsive, hitting capslock/numlock/etc. causes keyboard light to toggle, and I can still get to the virtual terminals at F1, F2, etc. I'm not positive, but I also suspect that the issue occurs during alt-tabbing. After waiting anywhere from 5-10 minutes, the keyboard magically starts working again. My thanks go to any devs actively working on this -- this is a really frustrating issue and I can't wait for it to be resolved. Same problem here, it looks like kwin sometimes randomly fails to ungrab the keyboard after Alt+Tab-bing between windows. Doing anything that makes it re-grab and ungrab again fixes the keyboard - the simplest such action that I have found is right-clicking on any window titlebar to bring up the window actions popup - right after the popup appears, keyboard becomes responsive again. I would say to just check the keyboard and update kde One of my friends has been experiencing this problem, and as the resident Linux expert, I've been assigned to fix it. He's running x86_64, Fedora 10, Qt: 4.4.3 KDE: 4.2.1. Please let me know of any additional information or testing I can provide. Created attachment 32663 [details]
lspci output
Please note that this is happening on an Intel backed machine, not just an nVidia one.
`lspci` attached.
SORRY FOR WRITING CAPITALISED; BUT MY SMALL 'E' KEY STOPPED WORKING COMPLETELY. SHIFT+E STILL WORKS. ALL OTHER KEYS WORK. IT HAPPENS AS SOON AS I LOGIN INTO X. I USE A NVIDIA CARD, KDE 4.2.69 AND OPENSUSE 11.1 I NOTICED STRANGE FOCUS IN AND OUT EVENTS IN XEV, WHICH DO NOT HAPPEN WHEN I PRESS OTHER KEYS AS WELL AS KEYMAPNOTIFY EVENTS XEV >>>>>>>>>>>>OUTPUT FOR PRESSING E.G. THE KEY 'r' KeyPress event, serial 34, synthetic NO, window 0x6400001, root 0x13b, subw 0x6400002, time 19462844, (26,36), root:(873,61), state 0x0, keycode 27 (keysym 0x72, r), same_screen YES, XLookupString gives 1 bytes: (72) "r" XmbLookupString gives 1 bytes: (72) "r" XFilterEvent returns: False KeyRelease event, serial 34, synthetic NO, window 0x6400001, root 0x13b, subw 0x6400002, time 19462939, (26,36), root:(873,61), state 0x0, keycode 27 (keysym 0x72, r), same_screen YES, XLookupString gives 1 bytes: (72) "r" XFilterEvent returns: False >>>>>>>>>>>>>>OUTPUT FOR PRESSING SMALL 'E' FocusOut event, serial 34, synthetic NO, window 0x6400001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 34, synthetic NO, window 0x6400001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 34, synthetic NO, window 0x0, keys: 59 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyRelease event, serial 34, synthetic NO, window 0x6400001, root 0x13b, subw 0x6400002, time 19464673, (26,36), root:(873,61), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False Sorry this (see above description) is actually not related to the bug. Someone pointed to me out that it is a hotkey setup problem and it indeed solved my problem. Wonder though how I set it, I never accessed this module... Note, killing kded4 and restarting kded4 causes a partial fix for me. The keyboard starts working, but hotkeys are ignored - alt-tab doesn't work, etc. This makes me think that the problem is in that module. This problem continued to occur for me on my m1330 for the past month; moreover, in that time, progress toward resolving the bug has been surprisingly limited. Unfortunately, this has been a deal-breaker for me; I removed KDE last week and am happily typing away under XFCE. I didn't particularly want to be "that guy" who broadcasts his departure as though his or her leaving makes any sort of difference-- I realise KDE is produced largely by volunteers and that it's unfair to ignore all of the good for the limited, albeit highly annoying, bad. My hope is that it might help underscore the importance of getting this serious bug resolved if the maintainers see their users quitting. Section "Serverflags"
Option "AllowDeactivateGrabs" "on"
# ^^^ use control + alt + keypad's divide
Option "AllowClosedownGrabs" "on"
# ^^^ use control + alt + keypad's multiply
EndSection
Is something you can add to your xorg.conf file to test things: If your keyboard vanishes, then try hitting control & alt & either "multiple" or "divide".
Also, nobody here is putting in what version of kde they are using. In almost any toolbar at the top of an application (Konqueror works), you will see "Help" ---> "About KDE" ---> a version number. Please put that in your report. "KDE4" doesn't help us very much, for example, the person above who lost their "e" key: that is a known bug, somewhere in the 4.1.x branch (I think...) that has been fixed. (Search for the closed bug report.)
If you try from a different user account, does this still happen? ie a "clean" account with default settings.
I talked to zarin about this last week. apparently it's an issue with the kde global shortcut stuff: it has a race condition with kwin for grabbing the keyboard... I forget the details, but it sounds hard to resolve... :/ btw, the workaround of right-clicking a titlebar and picking 'move' worked for me; seems anything that gets kwin to give its keyboard-grabbing a kick will unbreak it. makes the bug a lot less irritating. :) I have attempted several times to do the click thing you describe, Chani, but right clicking anywhere just resizes the window. The only way I've found to break out of it is a log-out and log back in. Restarting kded4 releases the keyboard lock, but then we lose all shortcuts (alt-tab, F keys...) Control-alt-keypad multiply appears to fix the keyboard issue for me, when it occurs. Unfortunately, it also causes the same problem that killing kded4 does: No alt-tab'ing, no hotkeys, etc. As I said before, this is on KDE 4.2.1, x86_64, Fedora 10. Confirming for 4.2.2 (amd64) Adding KWin people to the CC (as it seems to be related). Adding Kded/KHotKeys (shortcuts) people Changing severity to "major". Just to confirm something: When I experience this bug(or one of its variants) which is quite often (like 2 minutes ago) I simply like suggested use the mouse to un-maximise the window move the window or resize and then my keyboard comes back and starts working again. This time i first tried xev, after a while keyboard started showing up there if i held a key pressed over half a second. After that keys kind of responded very laggy in konsole. Resizing windows had no effect, other than causing even klauncher and menus to lag for a while. Then i went to the accessibility settings, disabled slow keys and kde started working ok again, note that i have NOT kept any key pressed for long, and didn't see that dialog pop up. In fact the keyboard was already dead when i started kde the last times. I will leave slow keys disabled now and see if that makes the problem go away,which might be another clue :) Just to confirm the problem on Fedora 10 x86_64 with KDE 4.2.2 and 4.2.3 Qt: 4.5.0 KDE: 4.2.3 (KDE 4.2.3) kde4-config: 1.0 *** Bug 185890 has been marked as a duplicate of this bug. *** I managed to get keyboard back by enabling slow keys and then disabling them again. There is also with steps to possibly reproduce. Can everyone having the problem try to reproduce according to the description there? Reproducing is the first step to solving the issue. http://bugs.kde.org/show_bug.cgi?id=188499 I can confirm to reproduce this behaviour with the steps described in http://bugs.kde.org/show_bug.cgi?id=188499. Just press Alt+Tab just after switching to the virtual desktop and the keyboard will stop working. After trying some time, I couldn't reproduce it reliable, but quite often. The chance is higher, if you have more than one window opened (on the desktop, you are switching to) and you are switching from a desktop with less opened windows. At least that seems what happens here. *** Bug 184785 has been marked as a duplicate of this bug. *** *** Bug 188499 has been marked as a duplicate of this bug. *** Btw there is bug https://bugs.kde.org/show_bug.cgi?id=137288 against 3.x . It seems like this is an x11 bug somehow triggered by some applications. I would love to work on the bug but can't reproduce it here. I had it for a short period but after upgrading my pc out of necessity (motherboard failure i never experienced the problem again) I did change global shortcuts handling for 4.3. Is someone experiencing the problem with 4.3beta packages or using trunk?. yep, I've been getting this semi-regularly in trunk (triggered by alt-tab). it seems to be happening more often in the last month, but maybe that's just coincidence. I experienced this twice last week, running KDE trunk (updated on wednesday). *I'm not sure* but I think it was triggered by alt-tab when the yakuake windows was the active one. *** Bug 193083 has been marked as a duplicate of this bug. *** Just thought that i'd mention i've configured shortcuts for switching desktop left, right, up, and down, control-alt-<cursor key>. Hope this helps. I've also configured shortcuts for switching desktop left, right control-alt-<cursor key> (not up/down though). same here. using the 4.3 beta packages from opensuse. the freeze used to happen very frequently with earlier versions. not so much now, but does happen occasionally. hi all. I'm also experiencing this bug from times to times. Though i'm kinda more lucky that most of the first reports i've read : after some times (~5minutes) it works again. I usually try the keyboard a lot so i dont know if waiting without doing nothing would solve it. I also switch to text mode a lot in this time. i'm using nvidia drivers, x11-base/xorg-server-1.5.3-r6 and NOT compositing as it's so buggy with nvidia. I'm currently using kde 4.2.4, though I've had the bug for quite some time. As a matter of fact i'm also using Yakuake a lot (some people report make me think this could be related). I could not find anything useful in Xorg.0.log or .xsession-errors but in kdm.log i have lot of lines like: --------------------- expected keysym, got dead_currency: line 501 of fr expected keysym, got dead_belowcomma: line 509 of fr ------------- i'm happy to help if i can, though i have no idea where to start. I suspected kxkb as I've had a lot of trouble with it before this. But i have no argument to support this feeling. For those who have lost their keyboard when using alt+tab directly after switching desktops: please try to activate the present windows effect by moving mouse into left upper screen corner. And select a window with the mouse. This restored the keyboard for me. It would be interesting to know if this is a general workaround. Two more ways (actually the only ones for me...) how to trigger this. At work I have to connect to net via a proxy. If I use Amarok 2.1 (did happen with 2.0, too) and activate "Automatically fetch cover art", keyboard stops working as soon as Amarok tries to fetch cover. If I switch to console and kill Amarok and possibly the kio_http it started, my keyboard starts to work again. Another way: Start Konqueror and try to browse around the web, again connection via a proxy. Go to some page which has slowly responding components and see how your keyboard stops working. Kill Konqueror + kio_http slaves, keyboard starts to work again. So maybe this is KIO related issue after all? I can reliably trigger this bug with both PC-BSD 7.1 + KDE 4.2.2 and Kubuntu 9.04 + KDE 4.2.4 (upgrading to KDE 4.3 beta 2 as we speak). My taskmanager displays windows _only_ from current desktop. I have tried may times to trigger this bug with Alt-tab and it does not affect me. Can any one try this out. (kde4.2.-svn-trunk from 11 june) (In reply to comment #81) > My taskmanager displays windows _only_ from current desktop. I have tried may > times to trigger this bug with Alt-tab and it does not affect me. I mean taskbar (in the panel). Sorry ! > > Can any one try this out. (kde4.2.-svn-trunk from 11 june) your taskbar has nothing to do with it, trust me. #################################################### a summary for those skimming the BR: alt-tab and similar shortcuts trigger the bug, doing anything that makes kwin re-grab the keyboard (like alt+click in a window) will unbreak it. if that's not the behaviour you're seeing, you've probably found a different bug and should open a separate report. #################################################### maybe we should make a new report for this bug, actually, with a summary, and close this one as a duplicate. the page is so long now that some people are just repeating what others have said without knowing it... (In reply to comment #83) That is not an accurate summary. For example, in my bug report (which was originally bug 193083 and then marked as duplicate of this one) I have not mentioned anything about Alt+Click being able to solve the problem -- in fact I just tried and can confirm that Alt+Click does not have that effect. Furthermore, some of the people above reported that they are unable to get the keyboard to work at all (without at least restarting X) while others (like myself) have found various methods to release the keyboard lock, e.g. using mouse clicks. This may indicate that the cause of the various problems is actually quite different in each case; and indeed many of them have been reported in separate bug reports anyway, which were then merged with this one. Therefore, by closing it and declaring it a duplicate of some over-simplified "summary bug", you would effectively get rid of all the individual bug reports -- without ever having solved them. A few things that would be more helpful include: a) to systematically try to reproduce any of the bugs reported above by following the problem descriptions very carefully. E.g. has anybody tried to run the Japanese input method in parallel, which may be one way to trigger the bug? b) if all fails, to give us some pointers to code that may be involved in the problem cause. E.g. somebody mentioned a possible race condition in Kwin -- what exact code would that be? Can I get access to that and is there a basic description of that code, so I could start to do some debugging myself? Or can more verbose debug messages be enabled somewhere? I can confirm this bug appearing sometimes around pressing Alt-Tab. BTW keyboard modifiers continue to work, for example Ctrl+Scroll works fine. Qt: 4.5.1 KDE: 4.2.4 (KDE 4.2.4) ATI Radeon X300 video card Compositing off I have this issue too. I have successfully recovered from this bug two times in a row doing this: 1. System Settings -> Accessibility -> Modifier keys -> Use Sticky keys -> Check 2. Apply 3. Use Sticky keys -> Uncheck Keyboard still not working 4. Start KCharSelect (for typing some text with copy/paste) After this keyboard started to work. *** Bug 196432 has been marked as a duplicate of this bug. *** This is just to confirm the bug once more and to add that ever since I switched to 4.2.4, it has become a _lot_ worse. On a typical day, I will run `DISPLAY=:0 kwin --replace &` once every 20 to 120 minutes. This may be only marginally helpful in finding the cause of the bug, but the problem I have reported (window-specific keyboard lock after using Alt+Tab) has improved slightly with some of the recent yum-updates. While before the changes, using Alt+Tab in a Firefox window, switching to a Konsole window _always_ triggered the bug, this is no longer the case. Switching from Firefox to Konsole works most of the time now, although sometimes the keyboard lock still occurs after typing a few characters in the Konsole window. The recent Yum updates made are as follows: Jun 26 17:20:56 Updated: libpurple-2.5.7-1.fc9.i386 Jun 26 17:20:57 Updated: libnetfilter_conntrack-0.0.99-2.fc9.i386 Jun 26 17:20:57 Updated: apr-util-1.2.12-7.fc9.i386 Jun 26 17:21:43 Updated: pidgin-2.5.7-1.fc9.i386 Jun 26 17:21:46 Updated: kio_sysinfo-20090620-1.fc9.i386 Jun 26 17:21:48 Updated: PyKDE4-4.2.4-2.fc9.i386 Jun 26 17:21:50 Updated: kernel-firmware-2.6.27.25-78.2.56.fc9.noarch Jun 26 17:22:21 Updated: AdobeReader_jpn-9.1.2-1.i486 Jun 26 17:22:46 Installed: kernel-devel-2.6.27.25-78.2.56.fc9.i686 Jun 26 17:23:07 Installed: kernel-2.6.27.25-78.2.56.fc9.i686 Jun 26 17:23:11 Updated: kernel-headers-2.6.27.25-78.2.56.fc9.i386 Jun 26 17:23:43 Installed: kernel-2.6.27.25-78.2.56.fc9.i686 Jun 27 21:58:48 Updated: poppler-0.8.7-2.fc9.i386 Jun 27 21:58:51 Updated: 7:kdenetwork-libs-4.2.4-3.fc9.i386 Jun 27 21:58:53 Updated: poppler-qt4-0.8.7-2.fc9.i386 Jun 27 21:58:54 Updated: poppler-glib-0.8.7-2.fc9.i386 Jun 27 21:59:06 Updated: pam_krb5-2.3.5-1.fc9.i386 Jun 27 21:59:44 Updated: 7:kdenetwork-4.2.4-3.fc9.i386 Jun 27 21:59:46 Updated: mozplugger-1.12.1-1.fc9.i386 Jun 27 21:59:48 Updated: poppler-utils-0.8.7-2.fc9.i386 Jun 27 22:00:45 Updated: 7:kdenetwork-4.2.4-3.fc9.i386 Jul 02 13:32:57 Updated: k3b-1.0.5-9.fc9.i386 Jul 02 13:33:01 Installed: GeoIP-1.4.6-1.fc9.i386 Jul 02 13:33:41 Updated: k3b-1.0.5-9.fc9.i386 Jul 03 14:15:35 Updated: strigi-libs-0.6.5-2.fc9.i386 Jul 03 14:15:37 Updated: 1:xorg-x11-xfs-1.0.5-2.1.fc9.i386 Jul 03 14:15:38 Updated: 1:xorg-x11-xfs-utils-1.0.5-2.1.fc9.i386 Jul 03 14:15:41 Updated: kdebase-runtime-libs-4.2.4-2.fc9.i386 Jul 03 14:16:07 Updated: kdebase-runtime-4.2.4-2.fc9.i386 Jul 03 14:16:49 Updated: kdebase-runtime-4.2.4-2.fc9.i386 Jul 04 14:20:17 Updated: libpurple-2.5.8-1.fc9.i386 Jul 04 14:20:19 Updated: libtiff-3.8.2-13.fc9.i386 Jul 04 14:21:03 Updated: pidgin-2.5.8-1.fc9.i386 Jul 04 14:21:05 Updated: mozplugger-1.12.1-2.fc9.i386 Also not sure how useful this is, but #88 is _only_ happening right after closing a window with alt-f4, usually followed immediately by a alt-tab. As f4 and tab are very near to each other on my X31 and I am a touch typist, we are really speaking about a few dozen or hundred milliseconds in between. SVN commit 993433 by mjansen: Try to fix the famous my keyboard is not working bug by providing CurrentTime to XUngrabKeyboard. According to the documentation if not doing that the ungrabbing can silently fail. I have no idea what that change really does but i ran it the complete day and noticed no difference. I had the problem yesterday on my laptop twice. Today it didn't occur. Please report back if running on trunk and the problem happens for you with this patch. CCBUG: 171685 M +4 -1 kglobalaccel_x11.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=993433 Will this make it into 4.3.0? I am going insane due to this bug. I haven't been able to trigger the bug since applying the patch. I think we should backport now. :) For great justice! (i.e. yes please) I have upgraded my system (from Fedora 9/KDE 4.2.2) to Fedora 11/KDE 4.2.4 and since then the problem did not occur. So I haven't tried the trunk version yet, and if that isn't backported perhaps other people want to consider a system upgrade too -- at least those people that reported a problem similar to mine. it's not fixed. :( I just triggered it again. on the bright side, alt+click is a reliable and easy workaround for the damn bug. After an HAL update last week the keyboard completely quit working in KDE. I could type on the login screen, but once KDE came up: nothing. I loaded Awesome as the window manager under KDE and the problem persisted. I replaced KDE with gnome and the problem disappeared. *** Bug 199030 has been marked as a duplicate of this bug. *** I just wanted to put this information here so it doesn't get lost. From: http://qt.gitorious.org/qt/qt/commit/9e5fa633913ef952ca4ef5312fe396bcfc885321 > In some cases we might get an invalid timestamp that is far away in > the future, so remembering it will break all consequent X calls that > require a timestamp because it just contains junk (for example > clipboard will stop working). This happens with XIM+SCIM pair - > whenever we start input method and type something to the widget, we > get a XKeyPress event with a commited string, however the 'serial' and > 'time' members of the XEvent structure are not initialized (according > to valgrind) and contain junk This could be related. I was forced to format last week due to pilot error on my part, however it allowed me the chance for more usability time with this particular bug. Using KDE 4.2.4, most recent release to the Arch Linux repos, this bug can begin at any time. When said bug appears, it requires holding down each key for two seconds or so before the pressed key appears onscreen. To briefly solve this bug and/or [possibly] disable it's entirety (your choice): - With the still-functional mouse, visit KDE's System Settings -> Advanced -> Service Manager -> Highlight KHotKeys and stop the service. If you wish to still use the service, start the service once again. If you wish to disable the service entirely, remove the check and click Apply. I can confirm, on stopping the service, things immediately began working as they should. Considering I'm not a wonderful fan of KDE hotkeys, this isn't a big deal for me. For someone who continuously uses said KDE hotkeys, it's understandable this could be a very large deal. Nonetheless, this is the quick, albeit dirty, way of handling the problem on a temporary basis. Using 4.3 over here, and seeing same beahviour. Will check the alt-click trick to see if it works on the next issue. i can confirm the bug is still there on kde-4.3/gentoo. I can confirm the bug is still there on KDE 4.3 (Kubuntu 9.04). I still suspect it's related to slow keys, and triggered by holding ctrl or alt key or similar too long. In some cases i did get keyboard response if holding key pressed for over a second. At least in 4.2.4, it was _not_ (only) related to holding the keys for long. Matter of fact, if anything it happened when I was really fast. In 4.3 I did not see the error, yet. since kde 4.3 it seems to occur a lot more often to me. Fortunately there's the workaround of righ clicking on a window title bar and choosing 'move the window', which indeed unblock the situation. I agree with comment #105, to me it is not related to slow keys. It often (always?) happen when i switch window or desktop. And i do that a lot, and i'm quite fast at using the keyboard (both typing and switching and such..). Dont know if it's related... if you're having trouble with slow keys, please file a separate bug report... this one is about the alt-tab issue (which I can't reproduce with trunk, yay!) Still a problem on OpenSUSE 11.1/KDE 4.3. Keyboard wedges on all three of my OpenSUSE 11.1/KDE 4.3 platforms (all 64 bit, one laptop w/ Intel GMA, a workstation w/ quad core/quattro graphics, a desktop w/ AMD64 dual core and NVidia consumer graphics card). OS: Ubuntu 9.04 + KDE It seems that this problem is happened when SCIM is being used on KDE as long as I tried. After change to UIM, this problem has never happened. I hope this helps. thanks, SCIM / UIM? SCIM => http://www.scim-im.org/ UIM => http://code.google.com/p/uim/ thanks, That also matches my earlier observations that the bug only occurred when Japanese input was turned on. Before my system upgrade, the default was SCIM; since the system upgrade (comment #95) it is no longer SCIM, and the problem does not occur any more. In that case your cause is different from mine. I have never used Japanese input. Please try `ps -ef | grep scim` or `ps -ef | grep skim`. If process exists, just kill it :) I checked and I don't have skim (or scim). But I made another observation which might help hunting this bug down: Today I triggered this bug again but instead of everything being as ALT was pressed continuously, it was CTRL now -> what I did: * put the system under load (most time I trigger this bug, that's the case!) * pressed CTRL+ESC to open the System Activity program * started typing my program's name (before the System Activity appeared!) * it appeared but did not allow any text to be entered so my guess on what is causing this bug is: When the system is under load, processing a key event and already receiving new events before that has finished, it "forgets" to release the original event. This also matches my experience with ALT+TAB as the first action and the ALT being blocked. I dont think this is related : i'm using an american keyboard and i have neither uim or scim installed. Re Comment #116: I see. But, just to clarify the intention of all that talk about Japanese: I did not mean to suggest that Japanese SCIM is the bug's definite and only cause. But it does seem to help trigger the bug, and I believe it would be worthwhile for whoever complained earlier that he would love to work on the bug but is unable to reproduce it, to try and reproduce it by installing that Japanese input method. On KDE 4.3.1, this procedure works also for me when the bug occurs >Just to confirm something: >When I experience this bug(or one of its variants) which is quite often (like 2 >minutes ago) I simply like suggested use the mouse to un-maximise the window >move the window or resize and then my keyboard comes back and starts working >again. *** Bug 208059 has been marked as a duplicate of this bug. *** I have same problem after update to kde-4.3. http://bugs.gentoo.org/show_bug.cgi?id=281615 I use Alt+1, Alt+2 ... and Alt+6 for switch between virtual desktops (6 desktops). When I switch them quickly, and use Alt+tab, then keyboard stops working sometimes. Remain works only Ctrl, Alt and BackSpace. Repair this problem is restart KDE at all, or press Alt + left button of mouse. evdev version: 2.2.4. Keyboard settings: setxkbmap -model evdev -layout us,ru -variant ,winkeys This problem iterates at several computers. In console this problem don't appears! :( Thanks. Reproducible: Sometimes Steps to Reproduce: 1. Create 6 virtual desktops. 2. Bind Alt+1,Alt+2, Alt+3, Alt+4, Alt+5, Alt+6 for switch them. 3. Switch them quickly, and switch between application inside desktops at Alt+Tab. 4. Keyboard stop working sometimes. Actual Results: Keyboard stop working, Remain works only Ctrl, Alt and BackSpace. Expected Results: Keyboard must work! Same problem here with OpenSUSE 11.1 and KDE 4.3.1. I have two shortcuts configured to rotate over the desktops: CTRL + LEFT to go to the previous desktop CTRL + RIGHT to go to the next desktop If I play fast with this shortcuts the problem appears soon. I was not able to found any workaround to recover the keyboard other than exit with CTRL + ALT + DEL. This is a show stop bug. We need a solution to this. KDE is not usable with this bug. Simular problem with openSUSE 11.1 with KDE 3.5 AND 4.1 moving mouse while loading some data in fresh opened openoffice or firefox stops any keyboard and mouse functionally. System access is by remote shell possible, only. Restarting KDE, X, switching runlevels don't reactivate mouse or keyboard. After rebooting the box all is fine up to the next above describben situation. Switching my PS/2 connected USB-mouse to a native USB-slot solved the problem. I hope this helps finding the problem. norbert: you say it breaks in OO.o or firefox, and restarting X won't fix it. I doubt your problem has anything to do with KDE. imho, this bug report should have been closed long ago, and separate reports started for the problems that *don't* go away when you alt-click a window. chani : I dont agree. This bug is still there (I currently use 4.3.2), i experience it every day, and use the turnaround cited in this bug report. Closing it would be like denying it...... a fairly bad practice imho. I can also confirm this bug and I'm using KDE 4.3.1. The most effective cure is to resize currently active window. After that keyboard starts working. Totally agree with orzel. Closing this bug will not make it go away. I wonder why alt+clicking should be expected to get a working keyboard back. It's not exactly user friendly... This bug was first reported on September 2008 and now we are on October 2009. More than one year and not solution yet. For me this is the worst ever bug with kde. It make this environment not usable for me. I think that all improvements in KDE are not valuable if the keyboard does not work wll. The keyboard is basic in the interaction with the computer. Problems like this makes people do a change of window manager environment. Please a "real" solution for this !!!. I must concur with Juan Valiño , this is the worst bug ever and it should be fixed, not hide away because some people do not endure it any longer. At first, it make my laptop almost unusable, I had to struggle every day at work and I almost switch to another dekstop environement. Now, I haven't been able to trigger it for while , so I'm pretty sure it is fixed for my configuration (Qt: 4.5.2, KDE: 4.3.1 , on a Fedora 10 - not 11), but clearly other people are still suffering for it... It seems some people misread Chani's comment. I read it as meaning that we should split this bug report into multiple new ones as it seems that many people are posting comments relating to different bugs in this one. This makes it difficult to debug the original bug as there is a large amount of noise in the report. She is NOT saying that this report should be closed as nobody has fixed it yet. She is NOT saying that losing the keyboard is acceptable. The problem with this bug is that a large amount of people don't experience it. This is especially problematic when the developers that work in the relevant code--such as myself--cannot reproduce the issue at all. It's hard to find broken code if it's not broken for you. >_< We need to find a pattern between all users that experience the problem. The issue could be relating to an application/toolkit grabbing the keyboard; it could be a daemon grabbing the keyboard; it could be KWin grabbing the keyboard; it could be from the keyboard focus being forced to a hidden window; it could be due to obscure user interactions causing an interlock freeze; it could be an X protocol race condition; it could even be the X server having a random spaz attack. It's very hard to say at this point with the information that has been presented. #129: Thanks for this post, I was planning to write pretty much the same you just did :) As one of the people who have experienced the behaviour described in the original report and someone who the alt-click trick worked for, I can say that I have been unable to reproduce it ever since 4.3.1 so from my pov, this _specific_ report can be closed and others should be openend, maybe with references to this one so everyone who happens onto one of the variants which are apparently still existing can get the whole picture. #127 and #128 : I dont agree with you, it's far from being the worst bug. At least there's a workaround... there are lot of bugs that seem trivial to fix and are here for very long. My personal favorite is https://bugs.kde.org/show_bug.cgi?id=179144 but there are plenty of them :-) #129 and #130 : There's something proposed on #91 I have no clue if this is good or not, and I dont even know if the patch is present in 4.3.2 .. maybe that would be a starting point for you ? As one of the people who have experienced the behaviour described in the original report and someone who the alt-click trick worked for, I can say that I have been *able* to reproduce it ever since 4.3.1 so from my pov, this _specific_ report cannot be closed and would have to be reopened with the same description... I might even add that it is worse since upgrade to 4.3.x (but since I got an upgrade of Xorg/kernel at the same time, it's difficult to know if an other element isn't making things worse) @lucas then maybe we should work on collecting the information you need to help find the problem @orzel not every users of KDE know the trick, nor knows alt+ctl+f2, nor would know where to look for information to learn the trick I can reproduce this too. For the sake of aiding the developers (I hope someone involved can reproduce this), here are the more important bits of my system setup: Gentoo Linux KDE 4.3.2 uname: Linux raider 2.6.31-gentoo #6 SMP PREEMPT Mon Oct 12 05:49:40 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux KWin with compositing enabled NVidia drivers 190.32 (GeForce 9700M GT card) X.Org X Server 1.6.3.901 (1.6.4 RC 1) Release Date: 2009-8-25 Input devices managed via Hal (not xorg.conf) The "Alt+Tab quickly" trigger seems to work for me quite reliably. Usually, when I trigger by accident, I seem to recall it happening after an alt+tab that closely followed a clipboard action (ctrl+c,alt+tab). Switching desktops or doing other compositing-heavy actions might help too, though it can definitely be triggered with compositing off. I think compositing just makes it more likely to happen. If you want to trigger it but can't, I suggest very quick alt-tabbing between applications interspaced with other actions: click on the virtual desktop icons on the task bar, type something, etc. In general, do stuff quickly while performing some sort of KWin keyboard action. I have been able to reliably trigger it 5-6 times in the past few minutes by doing this. As for workarounds, right clicking on the titlebar works most of the time. However, I was able to cause mouse activity to hang too at one point (the mouse moved, but nothing responded to clicks), so I suspect this may also be related to either mouse grabbing or some sort of broader kwin issue. Switching to a text terminal and killing/relaunching kwin fixed that one. I'm pretty rusty on Qt/KDE coding, but if no real developer manages to reproduce this, I would definitely be willing to work with one to try to track down and fix the issue. This bug is a hell. Many months with this bug forcing to me go out of KDE with CTRL+ALT+BACKSPACE, slowing and losing my work too many times. None of the workarounds pointed here works in my environment: CTRL+ALT+F2, CTRL+CLICK, ALT+CLICK. The only thing that works is to kill KDE with CTRL+ALT+BACKSPACE. I am fan o KDE for a lot of years, but because of this bug I am considering seriously switching to other environment where the keyboard works as expected. I can't work with the system in this condition. Sorry by this hard comment, but I am tired of this bug. Please, a solution for this. this is merely a helpless shot in the dark*, but can anyone who can reliably reproduce this issue try to change KDE/kdebase/workspace/kwin/workspace.h (~ line 134)
bool focusChangeEnabled()
{ return block_focus == 0; }
to
bool focusChangeEnabled()
{ return block_focus < 1; }
*the reason is that geometry.cpp, Worspace::setClientMoving() could /theoretically/ be called several times with a NULL parameter and in consequence this query being false forever and thus the kbd focus won't be passed on
I hate to say it, but at least with 4.3.1 (not 4.3.2) I managed to get the error, today. Thankfully, I know exactly what I did to get there and this time, I did not click or type fast, but rather slow & relaxed. I was using Konqueror to browse some websites. I clicked a link with the middle mouse button and Konqueror just disappeared, revealing the Konsole instance behind it and pasting the X copy buffer's contents into Konsole. I pressed alt-f2, "konq", enter and chose to restore the Konqueror session when prompted. From that time on, I did not have keyboard, any more. I used the mouse to go back to the Konsole instance, de-maximised it, pressed ALT, left-clicked into Konsole, moved it and everything went back to normal. I.e. this was the bug most of us can agree this specific report is about. I will upgrade to 4.3.2 soonish and report if I see it again (though I have not seen this one in ages (thankfully)) Still getting this bug with 4.3.2. Recently (not sure whether it came right with the 4.3.1 -> 4.3.2 upgrade, or later) I experienced the more severe variant of this bug again. Before, when the keyboard froze, I could fix it by starting system settings/accessibility, enabling slow keys, applying, and disabling them again. And the keyboard actually was not completely frozen, but incredibly slow. When I pressed a key for some 5 seconds, it was recognized. Now, the last few times the bug occurred, the "slow keys" trick no longer worked, but instead I had to restart kwin. In any case it is good to have a "restart kwin" desktop entry accessible easily with the mouse ;-) (In reply to comment #137) > Still getting this bug with 4.3.2. Recently (not sure whether it came right > with the 4.3.1 -> 4.3.2 upgrade, or later) I experienced the more severe > variant of this bug again. I should say that the workaround of invoking the "move" action (via a window's context menu, or via alt+click) also works. Just "slow keys" no longer works. (In reply to comment #135) > this is merely a helpless shot in the dark*, but can anyone who can reliably > reproduce this issue try to change KDE/kdebase/workspace/kwin/workspace.h (~ > line 134) > bool focusChangeEnabled() > { return block_focus == 0; } > to > bool focusChangeEnabled() > { return block_focus < 1; } > > *the reason is that geometry.cpp, Worspace::setClientMoving() could > /theoretically/ be called several times with a NULL parameter and in > consequence this query being false forever and thus the kbd focus won't be > passed on although I can somehow not reproduce this bug anymore (for now), I applied the patch to the rpm packages in my repository at http://download.opensuse.org/repositories/home:/NicoK:/branches:/KDE:/KDE4:/Factory:/Desktop/ for anyone who wants to try but does not want to compile it on his/her own (package is currently scheduled for build, and will be there soon). Is it possible that some fix was included in Qt 4.6? Because that's the most important update I did compared to last time I triggered the bug. (In reply to comment #139) > http://download.opensuse.org/repositories/home:/NicoK:/branches:/KDE:/KDE4:/Factory:/Desktop/ sorry, I forgot to mention, that those packages are build from the packages delivered by openSUSE Factory (http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Desktop/ which contains KDE 4.3.1 + some patches) and are thus only build for openSUSE (11.0, 11.1, 11.2, Factory, SLE11). Hi, this bug still present in kde4.3.3 I've noticed this for the first time ~2 months ago and with every kde update it appears more and more frequently. I'm using this computer for work, so I've switched to XFCE. After every update that brings fresh (kde || Xorg || hal) packages I log in to KDE, but this bug still exists - I always see this in less than 1 hour of work. It is possibly linked to a bug in xserver-xorg-input-evdev. I ran into this every so often with Kubuntu Karmic on my desktop. I don't know the upstream bug or patch information, but look at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/475718 to see if it is relevant. I am running with the ppa version of evdev and haven't seen a problem all weekend. It usually happen when I'm doing a lot of copy/paste (Ctrl+C, Ctrl+V). Looks like I'm pressing some strange combination instead. Restart kwin fix it. It usually happen when I'm doing a lot of copy/paste between applications (Ctrl+C, Ctrl+V, Alt+Tab). Looks like I'm pressing some strange combination instead. Restart kwin fix it. I have a similar problem, maybe the same, and I found how to reproduce it. (and have a not-so-nice workaround/fix). In my case, I get an almost complet keyboard lock, but NumLock and CapsLock do work. They turn on/off the LEDs, I mean. I cannot type anything, or use any hotkey. I was able to reproduce this under Mandriva GNU/Linux with KDE 4.3.2, but also all prior KDE 4 versions since 4.2.0. Both with kwin desktop effects and without them. Also reproduced under Arch GNU/Linux with KDE 4.3.3, without kwin desktop effects. How to reproduce: My setup consists of 2 desktops, and at least 2 windows open in each one. I have a hotkey for switching desktops (super+tab), but the bug happens also if I do following procedure using the pager-plasmoid to switch. Steps to reproduce: Switch from one desktop to the other, and quickly, switch windows with alt+tab, then quickly switch desktops again with super+tab or the pager, then alt+tab again. Pretty soon I hit the lockup condition, and no more typing in any window. Hotkeys don't work. My way to recover: With desktop effects enabled, having the "Present Windows" effect enabled, and assigned to be activated by placing the mouse in the top-left corner, I activate it, and keyboard starts working normally again. Hotkeys and everything. There's no crash, so no backtrace. Maybe I could try executing kwin (if its actually kwin's fault) from a console, and see the messages while doing my procedure... comment #135 may be on to something, I used to occasionally lose keyboard on resuming my laptop (1/5 or so), after using the patch suggested there, and 20+ suspend/resumes later, none. Nope - I can still reproduce the issue after comment #135's patch (switch desktops using plasma applet while alt+tabbing quickly). I just found a workaround. When keyboard stop working, I just press ALT and mouse left btn and do some window movement. It works. And then keyboard works again. That work-around has already been documented in this bug report, but thanks for attaching it, anyway. Better one too often than one too few. I've noticed that 99% of the cases when this bug hits me is when I do [Alt]+[Tab] to switch between apps and one of them is Krusader. With Krusader turned off I can work whole day without stepping on this bug. Additionally I can confirm that workaround proposed in several entries (eg. #148) - [Alt]+mouse to move the window - works for me too. fwiw, I never used Krusader, but then, I have not really been hitting this bug any more since 4.3.3 (if you guys mind me replying to every new post giving personal context, please say so. I want to help, not annoy :) Richard I have that bug about 10 times a work day, with KDE-4.3.3: kdebase-workspace-4.3.3-7.fc11.x86_64 (and all my KDE packages are from Fedora 11, with the "kde" repository from the KDE Fedora group, version 4.3.3 and release 7.fc11). I usually kill/restart kwin when that bug occurs. It did not know the workaround. While I have some time, I want to share my experience with this bug, hoping that it will help someone debug it: Using the packages in the backports repo, I used every KDE version from the one Kubuntu Jaunty came with to 4.3.2. I never experienced this bug once, even though I used both eclipse and skim extensively. As soon as I dist-upgraded to Karmic (which includes 4.3.2), I started experiencing this bug with no change after upgrading to 4.3.3. I occurs most prominently while using eclipse (but also quite frequently in all other programs). It seems to get worse with time. Also, both quitting skim and Alt-dragging work, where the former provides a permanent solution until I have to start skim again and the latter provides (very) temporary relief and only seems to work in eclipse. This bug also frequently occurs with the locked screen password prompt after returning from standby. The evdev patch mentioned in comment #142 has no effect. I tried with two applications: Firefox 3.6_beta2 and Thunderbird 3.0_beta4. I pressed Alt+Tab many times, combine slow and fast pressing. But happen only sporadic. So I changed strategy. I pressed Tab, kept it pressed and then quickly pressed Alt key repeatedly. With this, I always get a keyboard lock in several seconds. Nice trick, #154. Developers, listen up: an even more reliable way to trigger the bug is to hold down Tab and repeatedly hit Alt (the quicker the better). This ensures very quick application switching and many attempts to pop up and close the task switcher window, and works a lot more reliably. Make sure you have a few applications running at the time (more complex GUIs to be drawn might help trigger the bug). As #154, I can reliably trigger the bug within even 1-2 seconds after starting the procedure. What happens (to me) this way is that X (or kwin) has no reliable idea on the state of the ALT key. (I.e. when ever I left click a window i'm in moveresize) Pressing and releasing ALT /once/ safely clears the situation. Some statistic query: - who uses "evdev" and who "kbd" as keyboard driver? - usb vs. ps2 keyboards? - external global kbd event listeners (sc|kim, xbindkeys)? - desktop FX (composition), window change effect (flip, coverswitch, present windows, whatever) - focus model (click, follow mouse etc) - evdev - ps2/usb (both trigger it) - no global listeners AFAIK (except synergys, but stopping it makes no difference) - compositing is irrelevant, I can trigger it either way (no specific window switching effect either, just the standard window list) - click focus model (Windows style) (In reply to comment #154 and comment #155) Using this tab+alt trick I have, for the first time ever, been able to reproduce this bug. (In reply to comment #156) - kbd - USB - No IME or xbindkeys enabled - Desktop effects enabled, box switch - Click to focus The tab-holding and pressing alt is indeed a sure-fire way of reproducing the bug in less than two seconds. Thinkpad X31 evdev no listeners all eye candy off, tabbing simply puts the window on top. holding alt-tab shows an outline of the window that will go active if i release click to focus, kde defaults I was also able to reproduce the bug more reliably following comment #154. My configuration: * evdev * USB keyboard * no global keyboard listeners or IMEs that I'd be aware of, except for KDE's hotkeys * desktop effects: cover flow switch * focus follows mouse (In reply to comment #156) > - who uses "evdev" and who "kbd" as keyboard driver? evdev on all my three computers. > - usb vs. ps2 keyboards? Desktop: ps2, Two Laptops: probably ps2 as well > - external global kbd event listeners (sc|kim, xbindkeys)? No (not installed) > - desktop FX (composition), window change effect (flip, coverswitch, present > windows, whatever) Present window, but I can reproduce regardless on composition. > - focus model (click, follow mouse etc) Click I "reproduce" this bug quite reliably by switching desktops and immediately trying to switch windows. (CTRL+Fn, ALT+Tab) This is a normal usage, so it was quite annoying before I learned the right-click workaround. * kbd driver * USB keyboard * most probably no listeners * no composition, no effects * focus follows mouse (In reply to comment #162) > I "reproduce" this bug quite reliably by switching desktops and immediately > trying to switch windows. (CTRL+Fn, ALT+Tab) This is a normal usage, so it was > quite annoying before I learned the right-click workaround. - with compositing suspended - under heaver cpu load (gcc), i can - occasionally enter a mousegrab (as reported by xprop - restarting kwin clears it), but the keyboard (alt+tab, typing in focus'd windows) remains accessable *shrug* I noticed this awful bug on my kde 4.3.3 desktop (no problems before) and upgrading to 4.3.4 it still remains my problem may differ a little from previous descriptions: whatever I do, whenever the system wants, keyboard becomes frozen: it seems that the last key remains pressed because if I was typing something somewhere, e.g. "bye sweet", the result is "bye sweetttttttttttttttttttttttttttttttt..." this key-forever-pressed behaviour is not an hardware problem, because if I logout from kde session, using the mouse, the problem disappears I run on Archlinux, kde 4.3.4, the only thing different from standard distro packages is my self-build kernel 2.6.31, built from scratch vanilla and patched with Con Colivas BFS scheduler Does <ctrl>-<alt>-<f1> wait for tty 1 to appear <ctrl>-<alt>-<f7> fix the keyboard hang? I have had that one in the past, but not any more. no way, keyboard totally unresponsive, and if caps-lock was activated there's no way to disactivate it but logging out from kde session *** Bug 203804 has been marked as a duplicate of this bug. *** This looks like one nasty bug. Here is a thing to try out if you are having it - and if you feel confident about doing repairs from the console command line. You might need to, in case something goes wrong.
Log in as root. Make a backup copy of your present xorg.conf file. (On my system it can be found at /etc/X11/xorg.conf.)
Open the original xorg.conf and take a look. It would have several sections in it that describe input devices. (At least) one of these would be the keyboard. In my xorg.conf the keyboard section looked like this:
Section "InputDevice"
Identifier "Keyboard[0]"
Driver "kbd"
Option "XkbLayout" "dk"
Option "XkbModel" "microsoftpro"
Option "XkbRules" "xfree86"
Option "Protocol" "Standard"
Option "CoreKeyboard"
EndSection
If you have the "CoreKeyBoard" option, try commenting it out:
# Option "CoreKeyboard"
and instead put a new "CoreKeyboard" line in the ServerLayout section (unless it's already there, of course). Your modified ServerLayout section should look more or less like this. (Make sure the "Keyboard[0]" specification matches the one in the section where you out-commented the CoreKeyboard line. It might have a different number than 0.)
Section "ServerLayout"
Identifier "Layout[all]"
InputDevice "Keyboard[0]" "CoreKeyboard"
InputDevice "Mouse[1]" "CorePointer"
InputDevice "Mouse[2]" "SendCoreEvents"
Option "Clone" "off"
Option "Xinerama" "off"
Screen "Screen[0]"
EndSection
The new/extra line here is the first input device (the one that mentions "CoreKeyboard"). Save the modified file, then reboot your machine and see if this changes your keyboard behaviour. If not, just revert to the original settings by deleting the modified xorg.conf and renaming your backup copy "xorg.conf".
Now, why am I suggesting this?
I recently installed KDE 4.3 in a Sun VirtualBox 3.1.0 r55467 (with 1024 MB RAM, 128 MB graphics memory). The distro I used was the one on the DVD that came with Linux Format Magazine 126 (the 2009 Christmas edition). With all current patches installed, it reports the following version numbers:
openSUSE 11.1 - 2.6.27.39-0.2
KDE 4.3.2 release 5
After installing Sun's proprietary graphics and input device drivers (aka the "VirtualBox Guest Additions"), my keyboard went dead. Not intermittently dead, as in this present bug, but completely and utterly so. The only way to make use of the keyboard was to get out of the GUI and work in console mode. Rebooting the machine made no difference; the error simply persisted.
After some heavy experimenting (I shall spare you the details), I found out that I could revive the keyboard by restoring the backup copy that VirtualBox had made of my xorg.conf file. It kind of broke my graphics and mouse drivers, but I could type! I also found that I could (and can) switch the bug on and off by simply interchanging these settings in xorg.conf. With the "ServerLayout" approach I have a working keyboard - with the other approach there is nothing I can do. None of the little Alt-Click/Tab tricks detailed elsewhere in this thread had any effect in my case.
So isn't this a different bug altogether, then?
It might well be - in which case I apologize for bringing it up - but it might also be the case that the bug is the same, but that VirtualBox makes it behave worse than on a regular machine. Whatever is going on appears to be strongly related to timing issues (fast typing, etc.) - and running KDE in a simulator obviously changes the timing rules a bit, since the "real" CPU has to take care of two operating systems instead of just one. (My physical machine is a ThinkPad Z60m with a single 2 Ghz Centrino processor, running Windows XP.)
The point is, this is so very easy to test: Just find someone who has this bug and do the mods in xorg.conf (if they are not there already, of course). If nothing happens, you have ruled out one more potential cause of bug 171685. If something DOES happen, it ought to be possible to find out why these two core keyboard settings are not equivalent (as I believe they should be). This again ought to shed some light on the bug - and you might also be in possession of a surefire way to reproduce it: Get the Linux Format DVD and install it on VirtualBox, then set up the Guest Tools...
I realize, of course, that there is about an 80% chance that I am barking up the wrong tree. If that is so, perhaps this is a good time to close this bug and start afresh without my misguided comments.
Incidentally, I am writing this on my virtual KDE box and the keyboard has not failed me even once. When I type quickly enough, though, it does get stuck on an occasional letter, rrrrrrrrrrrrrrrepeating it for a second or two. I conclude that the Xorg keyboard does have some issues with timing, but they seem to behave rather differently depending on how the system is configured.
Sorry about the length of this comment. :(
*** Bug 218448 has been marked as a duplicate of this bug. *** *** Bug 219586 has been marked as a duplicate of this bug. *** Part of me loathes posting to such a long bug already, but there's a chance many of the effects witnessed here (esp key repeating) may be related to a bug in X: http://ajaxxx.livejournal.com/62378.html I can't say if it's related, but when I moved from kernel 2.6.31-BFS to 2.6.32 the problem have never happened yet! probably the problem born with the Kolivas scheduler... Another 'might be related, if not disregard' report: On a newly installed PC with Debian Sid & KDE 4.3.4, I lose keyboard focus about every hour. I suspect it has something to do with compositioning as this happens when I use the _mouse_ to switch tasks via the task bar. The alt-click trick works to remedy this. This still happens regularly for me with KDE 4.3.4. Restarting kwin always fixes it. One thing to note that may help diagnose the cause is that in previous versions of KDE 4 (and I'm sorry but I forget how far back) I had to restart kded4 to fix it instead. Probably Bug 184645 is a duplicate of this. There I found a solution how you can get back your keyboard, here it is: https://bugs.kde.org/show_bug.cgi?id=184645#c11 . For me it worked anno, and in 4.4 this haven't occured yet. I repeat: switching from kernel 2.6.31 to 2.6.32 the problem totally disappeared! in .31 I used the BFS patch, I can't say if it's related... and I can't say if .31 vanilla would have a similar bad behaviour my current .32 is completely vanilla and works perfectly I have "linux-suse 2.6.31.8-0.1-desktop x86_64" kernel with 4.4 RC 2 and neither I experience it. a simple kernel upgrade doesn't fix this bug. at least not for me. i tried kernel 2.6.33-0.20.rc5.git0.fc13.x86_64 from fedora rawhide on fedora 12. the keyboard freezes in the same way as it did with kernel-2.6.31.12-174.2.3.fc12.x86_64. Kernel upgrades are definitely not a fix. 2.6.32 here, and the bug is still there. I have the same problem in 4.3.4 with Archlinux. Confirming for 4.4.0 Oddly enough, after upgrading to 4.4.0 I can't seem to reproduce this now (at least not deliberately). I'm not going to say that 4.4 definitely fixed it, because it might have been another package / update, but something apparently did. With the Tab-Alt trick, I'm seeing different behavior now. Holding down tab and repeatedly hitting Alt does eventually stop the window switching, and while Tab is held down the rest of the keyboard does appear to stop working. However, releasing Tab immediately makes it work again, which effectively makes this a non-issue. It smells like a workaround was applied somewhere at some point. For me keyboard just stopped working in KDE 4.4.0. But it might be another bug. For me, I get key events when I keep a key pressed for something around three secods (still bad enough) and it happens exspecially often when I use gimp. I'm using Fedora 12 with kernel 2.6.31 at the moment I think that might be another bug. The one I (and others) were seeing occurred when performing certain WM actions and is probably related to grabbing the keyboard. You shouldn't be able to get any keypresses through (even by holding), and it should be triggered by some kind of WM action, especially Alt-Tab. Maybe try updating your kernel to .32? Christian had something like that and it went away after a kernel update, so maybe some people are seeing a totally unrelated kernel/Xorg bug. Same for KDE 4.4.1 on Fedora. I don't think it's fixed on 4.4.1, as I just had kwin grab focus for the mouse and allow only the keyboard to operate. Restarting kwin fixed it. OK, I can definitely say that I haven't experienced this bug since my last comment (#182). Whatever it is I upgraded, 4.4.0 or something else, fixed it. (In reply to comment #187) > OK, I can definitely say that I haven't experienced this bug since my last > comment (#182). Whatever it is I upgraded, 4.4.0 or something else, fixed it. Same for me. kdebase-4.4.2-1.fc12.i686 As the original reporter of this bug, I must say this problem used to pretty often and randomly. When it did occur, *sometimes* I was able to work around it by unmaximize the window then move the window around(with my mouse) which would unlock the keyboard as decribed earlier in the report. Anyway, I must say as I'm always using the latest stable packages, I haven't had this issue on 4.4.2 or even 4.4.0. Last time this happened to me must have been approx 6 months ago. Not sure if this is still a valid problem with anyone else using 4.4.2 ? I did not have that problem since upgrading to 4.4, either. I also haven't seen this bug in 4.4 as described, but it didn't disappear completely. Now instead of locking the keyboard, it stops the navigation through windows (or desktops). By that I mean that I press an appropriate control key (usually ALT), press tab, the list of windows (or desktops) appears - and then immediately disappears with me still holding the control key. It's not as severe, but it's still annoying :) I've still run into it on 4.x It is not due "improved accessibility for disabled persons"? Previously, approximately in KDE 4.1, I had the same problem, but it gone after disabling those special accessibilities. Hey, I just upgraded in Debian Sid from 4.3 to 4.4 and got this bug :( I am using a Thinkpad R52. The laptop's keyboard works fine, but the usb mouse and keyboard stop. x11vnc also works (dmesg does not show any error about the usb interface). This bug has nothing to do with usb vs. internal keyboards, and it also has nothing to do with the mouse. You're hitting a different bug. I can add, that with KDE 4.3.5 on gentoo I just had to quickly repeat alt+tab a few times to switch between windows and keyboard input locked up again! What the hell is with this bug? With KDE 4.4.4 being tagged today and beta1 of 4.5 released yesterday, I think it's fair to say that 4.3.5 is simply too old to be useful in this contenxt. Especially since there were a lot of reports that 4.4 improved things considerably. @Richard My kde 4.4.2 with fedora 11 stopped to work several days ago. So new version doesn't mean working version. Oleg: I did not mean to imply that all problems are over. Only that 4.3.5 has known issues which were fixed in 4.4 so reporting against it is not all that useful. repsons: Can you upgrade to 4.4.3 and see if this improves your situation? Richard, the next time I update I'll come back. I simply can't do now, sorry (it takes time to recompile all kde!). *** Bug 184645 has been marked as a duplicate of this bug. *** When I had this bug occur on a debian testing platform (sidux) 4.4.5 it "went away" when I unpluged the keyboard and mouse and plug them in again. I'm also under the impression this is fixed in 4.4, didn't experience the problem in a couple of months at least. I think I haven't had this since 4.4, at least with the 4.4.5 I'm currently running I could not reproduce it. Same here. I am closing this bug. If anyone still experiences problems, please just reply here and I will reopen it. I am experiencing a stuck Alt key phenomenon once in a while. KDE 4.4.5, Gentoo. It doesn't happen on my desktop, only on my laptop. If it's any help, I'll mention that I am using synergy (http://synergy-foss.org/), but killing synergy (on both machines) doesn't fix the problem. xev shows the alt keys changing status. Setting KDE to popup a notification on modifier key change shows both Shift and both Ctrl keys changing state no problem, but it is totally silent when I try to use either Alt key. Perhaps open a new bug, because IMHO, this bug has been fully resolved for quite a while. I haven't had this issue, or heard of anyone having this issue in a long time. |