Bug 461207

Summary: Assigning Window shortcut key cannot include "meta" key (the "Windows" key) or it will be modified to some weird key and fail
Product: [Plasma] kwin Reporter: Luke Lee <luke.yx.lee>
Component: inputAssignee: KWin default assignee <kwin-bugs-null>
Status: REPORTED ---    
Severity: normal CC: aspotashev, bugs.kde.org, dev, luke.yx.lee, nate
Priority: NOR    
Version First Reported In: 6.3.4   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=502639
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Luke Lee 2022-10-30 14:41:35 UTC 
SUMMARY
On Kubuntu 22.04LTS, whenever I assign a window shortcut key including the "Meta" key (the left "Windows" key), for example, "Meta+D" it will be immediately converted to a weird sequence "ៀ?" which is not a valid shortcut key.  This *only* happens on Kubuntu 22.04LTS, not on 20.04 or 18.04.

STEPS TO REPRODUCE
1. Open any window say an xterm, on Kubuntu 22.04 LTS
2. Right click on the title bar of xterm, move down to "More Actions" -> "Set Window Shortcut"
3. In the dialog box enters whatever key combination containing the "Meta" key (more exactly the left "Windows" key), say, "Meta+D" (Win+D)

OBSERVED RESULT
After the key combination is typed in the above dialog box, inn the beginning it will correctly show "Meta+D" but 1 second later it will be converted to the text "ៀ?".  If we try "Meta+Alt+D" it will become "Alt+ៀ?".  After we closed the dialog, that key combination has no effect at all.
After examine the xmodmap I found the following 3 keys initially are:

  keycode  64 = Alt_L Meta_L Alt_L Meta_L
  keycode 108 = Alt_R Meta_R Alt_R Meta_R
  keycode 133 = Super_L NoSymbol Super_L

I need to change them to the following to fix this issue.

  keycode  64 = Alt_L Alt_L Alt_L Alt_L
  keycode 108 = Alt_R Alt_R Alt_R Alt_R
  keycode 133 = Meta_L Meta_L Meta_L

EXPECTED RESULT
It supposed to keep what we typed in instead of modifying it into "ៀ?"
If I load the modified xmodkey as above, the this won't happen and the key combination works well as before (Kubuntu 20.04LTS).


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Kubuntu 22.04LTS
(available in About System)
KDE Plasma Version: 5.24.6
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3

ADDITIONAL INFORMATION
Comment 1 Luke Lee 2022-10-30 15:12:56 UTC 
Another observation and workaround is that, when the key input dialog appears, the first "Meta" (Windows key) key-down event will be immediate converted into " ៀ?, ...", at this moment keep the "Meta" key pressed and use mouse to click the "clear" button (the button with a cross "X" on it), then this " ៀ?, ..." will be erased then, keep holding the meta key, continuing the remaining key, say, "Z" for "Meta+Z".  Now this trick will also work without having to load the workaround xmodmap keys I mentioned in the previous comment.
Comment 2 Piotr Dobrogost 2025-04-08 12:35:55 UTC 
Is this still an issue in Plasma 6?
Comment 3 Alexander Potashev 2025-05-04 16:55:33 UTC 
Same here in Plasma 6:

Operating System: Fedora Linux 41
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.13.0
Qt Version: 6.8.2
Kernel Version: 6.13.11-200.fc41.x86_64 (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz
Memory: 15.4 ГиБ of RAM
Graphics Processor 1: Intel® HD Graphics 530
Graphics Processor 2: NVIDIA GeForce GTX 960M
Comment 4 Alexander Potashev 2025-05-04 17:17:57 UTC 
UPD: although the main symptom of converting Meta to a weird sequence is the same, the other symptoms are different here. My case is closer to this description: https://unix.stackexchange.com/questions/717243/kde-meta-key-not-working 

Pressing the left "Windows" key here (which I expect to act like Meta) is reported as "Multi_key" in xev:

KeyPress event, serial 40, synthetic NO, window 0x4a00001,
    root 0x686, subw 0x0, time 174387726, (90,53), root:(2312,1199),
    state 0x0, keycode 133 (keysym 0xff20, Multi_key), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: True

KeyRelease event, serial 40, synthetic NO, window 0x4a00001,
    root 0x686, subw 0x0, time 174387853, (90,53), root:(2312,1199),
    state 0x0, keycode 133 (keysym 0xff20, Multi_key), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
Comment 5 Alexander Potashev 2025-05-04 17:44:15 UTC 
I have figured it out: I have the Left Windows key set up as Compose key. Unfortunately, I don't have enough keys on the keyboard (Dell KB216t), so will probably have to stop using the Meta key :(
Comment 6 Wismill 2025-05-05 05:46:55 UTC 
I can reproduce the issue with left Meta/Win as Compose key on Plasma 6.3.4 (Wayland), although I get multiple square characters instead of just one. Note that it is not specific to left Meta: I get the same issue if using Menu as a Compose key. Note that the shortcut itself works, it’s just the display.

While  it makes sense that a combo is not possible (Compose if not a modifier), I suspect that there is an issue with the conversion of the keysym Multi_key to UTF-8. If the conversion is done using the libxkbcommon API somewhere in the stack (e.g. xkb_keysym_to_utf8), then in the case of Multi_key nothing is written in the string buffer, so if it was not 0-ed  then it would explain why we see garbage.