Created attachment 172568 [details] screenshot showin kwin debug console with key sequence SUMMARY When trying to set up modifier only shoftcuts, ALT+SHIFT works as expected, but SHIFT+ALT registers as META+ALT+SHIFT STEPS TO REPRODUCE 1. Open keyboard shortcut settings 2. Select a keyboard shortcut and press the "Add custom shortcut" button. 3. press and hold SHIFT, followed by ALT, then release both. OBSERVED RESULT The custom shortcut is assigned as META+ALT+SHIFT EXPECTED RESULT The custom shortcut should be assigned as ALT+SHIFT, or SHIFT+ALT (I'm not sure which makes more sense). SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Operating System: KDE neon Testing Edition KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.8.0-40-generic (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i7-12700H Memory: 31.0 GiB of RAM Graphics Processor: Mesa Intel® Graphics ADDITIONAL INFORMATION When doing this sequence with the kwin debug console, we can see that when ALT is held, it records the pressed key as META, with the modifiers include both ALT, SHIFT and META. See attached screenshot.
This is because in the default layout, shifted alt is meta (check out `xmodmap -pke | grep -i alt`). Unless we want to handle this as a special case, this should be marked as a duplicate of BUG 434988, which is about kde using shifted symbols instead of unshifted symbols.
Also, if I am reading the x protocol correctly [0], kwin should be generating Meta events under shift+alt: ``` Within a group, the choice of KEYSYM is determined by applying the first rule that is satisfied from the following list: The numlock modifier is on and the second KEYSYM is a keypad KEYSYM. In this case, if the Shift modifier is on, or if the Lock modifier is on and is interpreted as ShiftLock, then the first KEYSYM is used; otherwise, the second KEYSYM is used. The Shift and Lock modifiers are both off. In this case, the first KEYSYM is used. The Shift modifier is off, and the Lock modifier is on and is interpreted as CapsLock. In this case, the first KEYSYM is used, but if that KEYSYM is lowercase alphabetic, then the corresponding uppercase KEYSYM is used instead. The Shift modifier is on, and the Lock modifier is on and is interpreted as CapsLock. In this case, the second KEYSYM is used, but if that KEYSYM is lowercase alphabetic, then the corresponding uppercase KEYSYM is used instead. The Shift modifier is on, or the Lock modifier is on and is interpreted as ShiftLock, or both. In this case, the second KEYSYM is used. ``` [0] https://www.x.org/releases/current/doc/xproto/x11protocol.html#Keyboards
It seems that in the default keymap, shifted alt has been meta for more than 20 years.. https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/9bbda6bfbcc29a575ea3b5cb7bd2553767e80d53/symbols/pc#L216
So one has to wonder - if I have META assigned as the modifier-only shortcut to trigger the application launcher - why pressing SHIFT+ALT and releasing it not opening the application launcher? I will try to change the keymap and see how that improves it. This, I believe, is yet another reason why shortcuts should not use keysyms but the physical scan codes - also bug #453661, bug #453661, bug #462274, bug #444537, bug #434949 and probably many more I'm not familiar with.
(In reply to Oded Arbel from comment #4) > So one has to wonder - if I have META assigned as the modifier-only shortcut > to trigger the application launcher - why pressing SHIFT+ALT and releasing > it not opening the application launcher? Works for me on git, wayland, if alt is released with shift pressed. > This, I believe, is yet another reason why shortcuts should not use keysyms > but the physical scan codes - also bug #453661, bug #453661, bug #462274, > bug #444537, bug #434949 and probably many more I'm not familiar with. IMO native key codes are more reasonable than the physical scan codes. E.g., I use a hwdb config to map my CAPS_LOCK to ESC, and I would want shortcuts containing ESC to trigger when I press that key. If I understand correctly, using scan codes means it will still be interpreted as CAPS_LOCK. One potential issue with not using keysyms is we cannot get consistent behavior for default shortcuts like Ctrl++ under different layouts. Since the plus symbol has meaning, we might want users to use the physical key corresponding to the + symbol in their own layout. This is also what Qt does, and I am wary of deviating from that. (https://doc.qt.io/qt-6/qkeysequence.html#keyboard-layout-issues)
IMO there is value to providing a consistent shortcut experience within apps and globally in the DE. If Qt apps overwhelmingly use key syms, maybe we should also stick to that..
(In reply to fanzhuyifan from comment #5) > (In reply to Oded Arbel from comment #4) > > So one has to wonder - if I have META assigned as the modifier-only shortcut > > to trigger the application launcher - why pressing SHIFT+ALT and releasing > > it not opening the application launcher? > > Works for me on git, wayland, if alt is released with shift pressed. That is interesting - I cannot reproduce this on Neon testing (currently claiming 6.1.5). Using <Press SHIFT, P ALT, R ALT, R SHIFT> does not trigger the application launcher that is configured for META. Trying to use that sequence in the shortcut setting shows up as META+ALT+SHIFT (as mentioned on top) and then I can't actually trigger that with the same sequence (though using real META+ALT+SHIFT works). > IMO native key codes are more reasonable than the physical scan codes. E.g., > I use a hwdb config to map my CAPS_LOCK to ESC, and I would want shortcuts > containing ESC to trigger when I press that key. If I understand correctly, > using scan codes means it will still be interpreted as CAPS_LOCK. I'm not familiar with that concept. KWin debug console shows scan codes, Kxb symbols (keysyms) and Qt::Key codes - which I believe are Qt internal representation of keysyms. > One potential issue with not using keysyms is we cannot get consistent > behavior for default shortcuts like Ctrl++ under different layouts. I believe it was demonstrated, by you in bug #434988 and elsewhere (my pet peeve is bug #453661), that both approaches have their drawbacks and the current behavior causes quite a lot of grief (my Yakuake pull down terminal is not accessible when I'm on the Hebrew layout, which is ridiculous). > we might want users to use the physical key > corresponding to the + symbol in their own layout. This is also what Qt > does, and I am wary of deviating from that. > (https://doc.qt.io/qt-6/qkeysequence.html#keyboard-layout-issues) Qt has a lot of heuristics to try to extract meaning of the mess that is layout-specific keysyms, as detailed in bug #453661 and linked Qt bugs, and those heuristics cause a lot of damage in and of by themselves. Anyway - to keep moving forward, what I would suggest is that for modifier-only shortcuts - that are only resolved on release anyway, to take into consideration only the physical (or native key codes - I'm not sure how you'd go about getting those) and not keysyms. This would also allow you to take advantage of right vs. left side modifiers, as other operation systems do (in Windows RTL, CTRL_R+SHIFT_R are used to force paragraph direction to RTL).
As this is done by the keyboard layout, this does sound like it should just be tracked in bug 434988 *** This bug has been marked as a duplicate of bug 434988 ***
(In reply to fanzhuyifan from comment #5) > (In reply to Oded Arbel from comment #4) > > So one has to wonder - if I have META assigned as the modifier-only shortcut > > to trigger the application launcher - why pressing SHIFT+ALT and releasing > > it not opening the application launcher? > > Works for me on git, wayland, if alt is released with shift pressed. I've updated to Neon unstable, and now I get that too - and I don't like it at all, not even a bit: layout switching is something that you should be able to do very quickly, while typing long texts - when mixing English and non-English text (which is very common these days in many non-English contexts). If I press ALT+SHIFT quickly and release quickly, often I release the ALT before the shift and I get the layout switched while opening the application launcher (I have per-window layout switching, so the layout is switched for the launcher and not the windows I'm working on); while if I press quickly and trigger SHIFT first - I get the launcher open and no layout switching (this is less common because of how I trigger the keys with the thumb on ALT and pinky on SHIFT so the pinky needs to travel more and is slower - but it does happen from time to time). If the issue is just the xmodmap - why did the behavior change from 6.1 to 6.2? The 6.2 behavior makes ALT+SHIFT layout switching (which is the most common switching workflow due to legacy operating systems) to be almost unusable. One has to now be very deliberate about pressing ALT+SHIFT.
(In reply to Oded Arbel from comment #9) > I've updated to Neon unstable, and now I get that too - and I don't like it > at all, not even a bit: layout switching is something that you should be > able to do very quickly, while typing long texts - when mixing English and > non-English text (which is very common these days in many non-English > contexts). Yeah I get all that, and I think the proper way to fix this is to support shortcuts based on keycodes, which is basically how it is implemented in xkb. A quick and dirty workaround would be removing Meta from shifted alt in xmodmap..
I've removed the mapping of shifted Alt_R to Meta_R by editing the file /usr/share/X11/xkb/symbols/pc and changing the line key <LALT> {[ Alt_L, Meta_L ]}; to key <LALT> {[ Alt_L, Alt_L ]}; (just removing the second definition causes the display server to stop handling keyboard events all together, this is probably an illegal syntax for some reason, even though other lines in that file have identical syntax). This is a workaround that will not survive a software update and as far as I can tell there is no way to for a user on Wayland to have a personal symbol map (at least as per some askubuntu answers). The actual issue is discussed kglobalaccel MR!53 and kwin issue 228. This info here is just for people who manage to stumble on this behavior, especially re: recent youtube videos on the subject.
(In reply to Oded Arbel from comment #11) > I've removed the mapping of shifted Alt_R to Meta_R by editing the file > /usr/share/X11/xkb/symbols/pc and changing the line > > key <LALT> {[ Alt_L, Meta_L ]}; > > to > > key <LALT> {[ Alt_L, Alt_L ]}; > > (just removing the second definition causes the display server to stop > handling keyboard events all together, this is probably an illegal syntax > for some reason, even though other lines in that file have identical syntax). > > This is a workaround that will not survive a software update and as far as I > can tell there is no way to for a user on Wayland to have a personal symbol > map (at least as per some askubuntu answers). The actual issue is discussed > kglobalaccel MR!53 and kwin issue 228. This info here is just for people who > manage to stumble on this behavior, especially re: recent youtube videos on > the subject. Check out https://wiki.archlinux.org/title/Xmodmap#Custom_table for ways to cuatomize your key map. If on wayland .Xmodmap is not automatically read, you can do this by setting something to run xmodpad ~/.Xmodmap. This is also persistent across updates. Also do you mean kglobalacceld MR53?
*** Bug 493890 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 494579 ***