It's quite simple: Every global shortcut where the Tab key is involved does not work for me anymore. If I assign a sequence containing Tab to a local short (i.e. Ctrl+Tab in KF5-based konsole), it works fine. But setting a global shortcut (i.e. Ctrl+Tab or Alt+Tab for krunner or kwin) does not. Setting a sequence not containing Tab (i.e. Ctrl+Alt+e) to the exact same shortcut works fine. Afaics, only the Tab key is affected, I didn't yet find any other disfunctional keys, didn't try all, though. On IRC, there were reports from other people telling me, that it works for them, though. Reproducible: Always Steps to Reproduce: 1. Check krunner shortcut (Alt+Space) is working 2. Set it to (Ctrl+Tab), check if it is working Actual Results: Alt+Space works, Ctrl+Tab doesn't. Expected Results: Both should work. frameworks is a version 5.3.0. Checked with master as well, though.
I wonder if other people can reproduce this problem and if not, why. I have now installed Plasma 5 on my laptop, which is running Fedora (21 + Plasma 5) instead of Exherbo, doesn't share configuration and still, I am able to reproduce this.
Just want to note, I tried some other combinations and Meta+Tab does not work as well.
Ok, I was able to track this down some more, especially, I was able to find out, why I'm seeing this and apparently nobody else. ;) Again, it is triggered by me using the neo layout [1]. As I want to use this layout at login as well, I put a file like this in /etc/X11/xorg.conf.d: Section "InputClass" Identifier "Keyboards" MatchIsKeyboard "True" Driver "evdev" Option "XkbLayout" "de" Option "XkbVariant" "neo" Option "AutoServerLayout" "on" EndSection That alone shouldn't be problematic and wasn't during KDE4 times (and in Plasma5 up to some point). In current Plasma 5 however, it seems to be an issue. Therefore when Plasma 5 is loaded, the keyboard layout is already switched to said layout and that seems to trigger the bug mentioned above. If I remove the file (so the us layout is picked as default) and make sure that the Plasma 5 keyboard switcher doesn't set the neo layout (just disabled the keyboard switcher for the time being), the issue does not arise. So it could either be a bug in the keyboard layout (meaning in xkeyboard-config) or in kglobalaccel. Reason against the former is that after login with the us layout, I can switch to neo using `setxkbmap de neo`and Alt+Tab will work just as expected. So I still believe that this is a bug in kglobalaccel. So at least I do now have a workaround, but obviously, I don't like to login using the us layout. ;) To reproduce (I suggest using an easy type-able password on a testuser) : 1. put a file `keyboard.conf` like the above in /etc/X11/xorg.conf.d 2. (Re)start the X server/login manager 3. Be aware, that the keys changed, refer to [1] for letter positions when logging in 4. Note that the Alt+Tab shortcut doesn't work anymore 5. Remove the file created in step 1 6. (Re)start the X server/login manager 7. Log in 8. Switch by executing `setxkbmap de neo` 9. Note that Alt+Tab will work [1] http://www.neo-layout.org
Yes, that sounds like a bug in kglobalacceld. In fact I think it could be related to bug #341959. I'm currently still at loss on how to properly test the situation.
Not sure if or how it is related. I can't use those shortcuts as well, but it doesn't matter which layout I set. Shortcuts using the Shift key don't work. Is there something missing from the testing sequence above? Which steps are not clear?
> Is there something missing from the testing sequence above? Which steps are > not clear? Sorry that was not clear from my side: I meant "test the situation in a unit test"
I can confirm this bug with a similar constellation: I have „Neo“ set as keyboard layout on system level (so even my system consoles and the login screen use it, as well as KDE). Under KDE4, Alt+Tab or Super_L+Tab could be used for switching between windows. Under KDE5 (Kubuntu 15.04, KDE-Plasma Version 5.3 and earlier) it does not work any longer. Instead, the „Tab“ is handed over to the currently active application. Switching input method within KDE (e.g. to QWERTZ or QWERTY) does not improve the situation (Alt+Tab still without effect). Alternative shortcuts (e.g. Alt+x) work though.
I can also confirm this with KDE Frameworks 5.9, and that it only happens if you configure X11 to use the neo layout on startup.
*** Bug 348298 has been marked as a duplicate of this bug. ***
From latest dupe: --------------------------------------------------------- This is the xev output for pressing Alt-Tab: KeyPress event, serial 37, synthetic NO, window 0x8800001, root 0x293, subw 0x0, time 5181172, (-304,488), root:(478,512), state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x8800001, root 0x293, subw 0x0, time 5181699, (-304,488), root:(478,512), state 0x8, keycode 23 (keysym 0xff09, Tab), same_screen YES, XLookupString gives 1 bytes: (09) " " XmbLookupString gives 1 bytes: (09) " " XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x8800001, root 0x293, subw 0x0, time 5181835, (-304,488), root:(478,512), state 0x8, keycode 23 (keysym 0xff09, Tab), same_screen YES, XLookupString gives 1 bytes: (09) " " XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x8800001, root 0x293, subw 0x0, time 5182723, (-304,488), root:(478,512), state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
*** Bug 347788 has been marked as a duplicate of this bug. ***
Thanks (I should have searched for "neo", too, when I looked for dupes). Sounds like bug #341959 contains an explanation indeed. However, creating a unit test for this requires deep X11 knowledge. I do not even understand how Neo implements six layers (see http://www.neo-layout.org for an immediate preview of the layout) when there may only be up to four KeySyms associated with a KeyCode. If there are better tools than "xev" to debug this, I am all ears.
I'm not sure that bug #341959 is actually related. a) There's no "shift" in "alt+tab" b) your xev log looks normal (keysyms & states are just like a normal german keyboard) c) if this was about some n-shift modifier (numlock, capslock, alt+gr, whatever) not being selected correctly, I'd expect pretty every global shortcut to fail - but the bug claims that this is a limited problem. Yet, if kglobalaccel would effectively grab those combinations, xev should not receive them...
(In reply to Thomas Lübking from comment #13) > I'm not sure that bug #341959 is actually related. > > a) There's no "shift" in "alt+tab" At least, one of the unusual things that Neo does is to have more than Tab and Reverse-Tab on that key. In particular, on layer 3, the tab key has the "Compose"(!) function, i.e. it allows you to press [Mod3]+[Tab], [`], [a] and you'll get "à". Now, [Mod3] is exactly [Alt] (also remapped to the CapsLock key), so these are interesting facts I think. On the other hand, that is no proof about the relatedness of the two bugs yet, agreed.
(In reply to Hans Meine from comment #12) > Sounds like bug #341959 contains an explanation indeed. However, creating a > unit test for this requires deep X11 knowledge. I don't think so. That bug reminds me very strongly about bug 338487, which was caused by an upstream Qt bug. See the Qt bug Florian Jacob linked there. So in case of bug 341959, it would be interesting, if it occurs after said patch was applied to Qt (or when a newer Qt is used. I think >=5.4.1 should be ok). > I do not even understand how Neo implements six layers (see > http://www.neo-layout.org for an immediate preview of the layout) when there > may only be up to four KeySyms associated with a KeyCode. xkb has a concept of a level5 modifier. I think it would be possible to get up to 9 layers. Neo doesn't use those due to ergonomic reasons, as Shift+M3+M4+Key wouldn't really be feasible anyway (and possibly not working on some keyboards due to hardware restrictions). Shift+M4 also isn't considered as a separate layer, since you might want to use Shift in combination with the movement keys on layer 4 to select text. It's a very clever concept if you spend the time to learn it. I'm glad I did so approx. 7-8 years ago. ;)
I can confirm the problem: Global shortcuts involving "Tab" don't work. Additionally all global shortcuts making use of the arrow keys, the numpad block or DEL/INS/POS1/END/PageUp/PageDown have also no effect.
Hi, with the German layout i got a similar problem. In the configuration widget my configured and pressed keys are shown. Whoever later the global shortcut react to "us" layout, not my german layout. So If I configure it to react to: meta+y It will react to: meta+z True for othery "remapped" keys too.
(In reply to Tetja Rediske from comment #17) > Hi, > > with the German layout i got a similar problem. In the configuration widget > my configured and pressed keys are shown. Whoever later the global shortcut > react to "us" layout, not my german layout. > > So If I configure it to react to: > > meta+y > > It will react to: > > meta+z > > True for othery "remapped" keys too. Did you check if the layout is set globally or per application? In any case, I doubt that this is related to this bug report.
It is set by Xorg like below: Section "InputClass" Identifier "keyboard-all" Driver "evdev" Option "XkbLayout" "de" Option "XkbRules" "xorg" MatchIsKeyboard "on" EndSection
Unfortunately, that doesn't mean that kded won't change it if you tell it to. So check your settings in systemsettings -> input devices and see if that helps.
I activated this function and it worked like expected, still IMHO a Bug, shouldn't ignore xorg base setting, if this function is disabled.
You activated "what" to get it work? I've nothing enabled there, a german kbd layout and Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" MatchProduct "Microsoft Comfort Curve Keyboard 2000" Option "XkbLayout" "de" Option "XkbVariant" "deadgraveacute" Option "XkbModel" "microsofccurve2k" Option "XkbOptions" "terminate:ctrl_alt_bksp,compose:caps" Option "XkbRules" "xorg" Option "XkbKeycodes" "evdev" EndSection what works as expected. This actually sounds more as if the keyboard is initially *not* configured (ie. your xorg.conf snippet does not apply for unknown reasons), kglobalaccel (4 or 5?) starts with US layout and doesn't catch the re-map event. Either way, this is completely unrelated to this bug, so please open a new one with the required information (and attach me, otherwise I won't see it)
I can confirm this bug. My xorg server was configured to use the neo2 keyboard layout, too. As soon as I remove the corresponding config file in /etc/X11/xorg.conf.d, all global shortcuts around the Tab key start working. The problems started exactly when I moved from KDE4 to Plasma 5. My box runs on Gentoo GNU/Linux using KDE 4.14.3 applications on top of Plasma 5.
Tetja encouters somewhat unrelated bug #350816
I just upgraded to xorg 1.18 and switched from evdev to libinput as keyboard driver, and now I can't reproduce this bug anymore and set the layout to neo upfront for xorg so that it works in the login manager again, found no problems so far. :)
Fixed for me as well now, but I don't know whether it's related to libinput. How do I find that out?
The most simple way to test the libinput driver relation is to remove xf86-input-libinput (and ensure xf86-input-evdev is installed!) As alternative, have an /etc/X11/xorg.conf.d/10-keyboard.conf: Section "InputClass" Identifier "Keyboards" MatchIsKeyboard "True" Driver "evdev" Option "XkbLayout" "de" Option "XkbVariant" "neo" Option "AutoServerLayout" "on" EndSection This might be due to https://git.reviewboard.kde.org/r/124710/ (because tab is on several "levels" and I'm not sure how they're implemented) or indeed https://git.reviewboard.kde.org/r/124893/ Both are in frameworks 5.16 Or it's actually a problem in evdev.
Tested again using fw 5.16 and evdev 2.10.0 and it indeed seems to be fixed. Looking at the evdev commit history I doubt that it's a bug that was fixed there, most of the commits seem to be related to pointer devices. If you're interested, I can test the linked patches, but I guess it doesn't matter too much. Anyway, I think this can be marked resolved.
One of them will have fixed it. If you ever happen to have to recompile kglobalaccel, feel free to try to revert either - might tell us interesting things about the implementation of the neo layout (but is not worth the extra effort)