From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: When caps lock is on, I cannot switch focus to windows with alt-tab, or change virtual desktops with ctrl-alt-arrow keys; hitting the keys yields no results, the task switcher window does not pop up either. This happens immediately after I start Gnome. The only 2 things I thought might interfere were Acme and an xmms-itouch plugin which I made sure were disabled. I also tried running xev in a terminal, it shows keycodes when I use the mentioned key combinations with caps lock on (just to be sure it wasn't my keyboard). Another strange thing that happens when caps lock is on is I cannot focus windows by clicking IN them, I have to click on the window's titlebar to focus to it. Version-Release number of selected component (if applicable): metacity-2.4.34-3 How reproducible: Always Steps to Reproduce: 1. start Gnome 2. turn caps lock on 3. try alt-tab, or ctrl-alt-arrow, or click inside a window to focus. Actual Results: key combinations yield no results, task switcher doesn't show up. clicking inside a window does nothing either. Expected Results: focus should change Additional info: It might be irrelevant, but I use a Logitech Access Keyboard (ps/2)
what is the output of "xmodmap" on your system? If you start "xev" and focus it and press CapsLock+Alt+Tab, what does xev print to the console? (It should print some KeyPressEvent, if you could paste the description of those events it would be helpful.)
Here's the output: $ xmodmap xmodmap: up to 2 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Alt_R (0x71) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x73), Super_R (0x74) mod5 ----------------------- KeyPress event, serial 25, synthetic NO, window 0x4600001, root 0x48, subw 0x0, time 40115277, (110,-12), root:(116,8), state 0x10, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyRelease event, serial 25, synthetic NO, window 0x4600001, root 0x48, subw 0x0, time 40115482, (110,-12), root:(116,8), state 0x12, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 25, synthetic NO, window 0x4600001, root 0x48, subw 0x0, time 40116491, (110,-12), root:(116,8), state 0x12, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 25, synthetic NO, window 0x4600001, root 0x48, subw 0x0, time 40116985, (110,-12), root:(116,8), state 0x1a, keycode 23 (keysym 0xff09, Tab), same_screen YES, XLookupString gives 1 bytes: " " KeyRelease event, serial 25, synthetic NO, window 0x4600001, root 0x48, subw 0x0, time 40117310, (110,-12), root:(116,8), state 0x1a, keycode 23 (keysym 0xff09, Tab), same_screen YES, XLookupString gives 1 bytes: " " KeyRelease event, serial 25, synthetic NO, window 0x4600001, root 0x48, subw 0x0, time 40117728, (110,-12), root:(116,8), state 0x1a, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: ""
Looks like NumLock is enabled also, though that should not matter either. I'll have to look at it in more detail.
Strange enough it does matter, everything I mentioned works fine without NumLock on. xev with Caps on and NumLock off: KeyPress event, serial 25, synthetic NO, window 0x4600001, root 0x48, subw 0x0, time 41316308, (879,541), root:(891,581), state 0x0, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyRelease event, serial 25, synthetic NO, window 0x4600001, root 0x48, subw 0x0, time 41316434, (879,541), root:(891,581), state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 25, synthetic NO, window 0x4600001, root 0x48, subw 0x0, time 41316884, (879,541), root:(891,581), state 0x2, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: "" FocusOut event, serial 25, synthetic NO, window 0x4600001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 25, synthetic NO, window 0x4600001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 25, synthetic NO, window 0x0, keys: 2 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 VisibilityNotify event, serial 25, synthetic NO, window 0x4600001, state VisibilityFullyObscured FocusOut event, serial 25, synthetic NO, window 0x4600001, mode NotifyNormal, detail NotifyNonlinear PropertyNotify event, serial 25, synthetic NO, window 0x4600001, atom 0x126 (_NET_WM_ICON_GEOMETRY), time 41317558, state PropertyNewValue PropertyNotify event, serial 25, synthetic NO, window 0x4600001, atom 0x126 (_NET_WM_ICON_GEOMETRY), time 41317565, state PropertyNewValue
I see the problem; if you don't have a ScrollLock on mod5 (as I do, and most people might) you get bitten by a bug in metacity/src/keybindings.c where the "<" should be "<=" Fixing in CVS now, will be fixed in RHL next time we update metacity. An easy short-term workaround is to put Scroll_Lock on mod5. Thanks ignored_mask = 0; while (ignored_mask < (int) display->ignored_modifier_mask) { if (ignored_mask & ~(display->ignored_modifier_mask)) { /* Not a combination of ignored modifiers * (it contains some non-ignored modifiers) */ ++ignored_mask; continue; } ... etc.
I will try that. Strange that this also affects gaining focus with the mouse, then again I don't really understand the inner workings here. Thanks alot for your help.
Fixed in 2.6.2 (or should be)