I have a rather odd issue with using Ctrl+Esc to be my task switcher. The reason I do this is that I remap my keyboards to conform to the old space cadet layout for Emacs, ie) Super > Alt > Ctrl > S P A C E < Ctrl < Alt < Super, and on top of that I swap Caps_Lock and Escape, thus Ctrl-Esc is less of a stretch and more comfy than Alt-Tab. Here is my .Xmodmap: http://pastebin.com/NApPyjEq The issue I'm having in KDE (but not any other desktops or window managers) is that Ctrl-Esc works fine with the left Ctrl, and when I use reverse task switching with both Ctrls (ie: I also map Ctrl-Shift-Esc to reverse task switching, as you'd expect). However, when I use the right Ctrl with Esc it just tabs back and forth between the last used application without ever showing the task switcher. This is particularly annoying as the right Ctrl is the one my muscle memory is used to using with Escape, as I like to use a modifier on one hand and the modified key on the other. I have unmapped Ctrl-Esc's default bindings - ie) the task manager and the standard close alternate keybinding. Reproducible: Always Steps to Reproduce: 1. Use linked .Xmodmap with UK keyboard. 2. Unbind Global task manager ctrl-esc binding and standard close ctrl-esc alternate binding. 3. Open Window Behaviour and Task Switcher section and bind Forward All Windows to Ctrl-Esc and Reverse All Windows to Ctrl-Shift-Esc. 4. Press Right Ctrl + Esc Actual Results: Switches window to previous window without showing task switcher. Repeated presses just switch back and forth between the same window. Expected Results: Bring up the Task Switcher. This does happen if the above I am using KDE 4.14.6 on Slackware with a UK keyboard.
Just to be sure: you actually press AltGr + CapsLock, right? Is this also a problem with the unmapped ctrl keys, ie. if you press R_Ctrl+CapsLock resp. even R_Ctrl+Escape (all keys references meant "physical") Can you trigger other shortcuts with this combination (eg. show krunner or whatever)? If not, what happens instead?
(In reply to Thomas Lübking from comment #1) > Just to be sure: you actually press AltGr + CapsLock, right? That's correct. > Is this also a problem with the unmapped ctrl keys, ie. if you press > R_Ctrl+CapsLock resp. even R_Ctrl+Escape (all keys references meant > "physical") Sorry, I'm not sure what you meant by unmapped ctrl keys. Do you mean the Physical Ctrl keys (which are now Super keys with my Xmodmap)? I actually have them mapped to go back and forth through Activities with Escape and shift-esc respectively, and that works as expected. I also have Alt-Esc and Alt-Shift-Esc mapped to task switch the windows of an application, and that also works as expected on both sides of the keyboard. It's just the remapped ctrl keys that are causing the issues. Also, worth noting, is that if I use a default map (ie: without my Xmodmap) then Ctrl+Esc works as expected both sides. There is something that breaks it by remapping right ctrl to Alt-Gr... But as I said before, I haven't had this issue with any other window manager (Xfwm, fvwm2, cwm, wmaker, fluxbox, openbox, spectrwm and whatever the Gnome one is!). > Can you trigger other shortcuts with this combination (eg. show krunner or > whatever)? > If not, what happens instead? Yes. I just tried mapping krunner to Ctrl+Esc and it worked as expected with both (virtual) Ctrl keys (physical Alt and AltGr).
> Also, worth noting, is that if I use a default map (ie: without my Xmodmap) then Ctrl+Esc works as expected both sides. That's what I wanted to know, yes. > I just tried mapping krunner to Ctrl+Esc and it worked as expected with both (virtual) Ctrl keys (physical Alt and AltGr). Ok, means the shortcut (very likely) gets invoked, but kwin shuts down the tabbox. => areModKeysDepressed() will return false, thus trigger the single stepping. Probably because areKeySymXsDepressed() is out of sync with the Qt key event (one taking xmodmap into account, the other doesn't) Archiving the problematic xmodmap (please don't use pastebin for bug-related stuff): ----------------- keysym Alt_L = Control_L keysym ISO_Level3_Shift = Control_R keysym Super_L = Alt_L Meta_L keysym Print = Alt_R Meta_R keysym Control_L = Super_L Hyper_L keysym Control_R = Super_R Hyper_R keysym Caps_Lock = Escape keysym Escape = Caps_Lock keysym XF86WakeUp = Menu clear control clear lock clear mod1 clear mod4 clear mod5 add control = Control_L Control_R add lock = Caps_Lock add mod1 = Alt_L Meta_L Alt_R Meta_R add mod4 = Super_L Hyper_L Super_R Hyper_R
I assume the issue is in Qt5, eg. try to use the 3rd level shift to enter a char in either a Qt4 or a Qt5 client. (Restarted) Qt4 works (eg. "phy_ctrl + +" => ~ on qwertz but Qt5 doesn't (no output at all) Same on your side?
The relevant code in kwin to figure out whether a modifier is hold got ported from XLib to XCB during the switch to Qt5. This means that it is possible that the problem got fixed. As we no longer maintain 4.x I am setting this bug to unmaintained.