Summary: | Remapping Num Lock with xmodmap breaks all Alt+* key shortcuts in KDE! O_OOO | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kglobalaccel | Reporter: | Vitaliy Filippov <vitalif> |
Component: | general | Assignee: | Martin Flöser <mgraesslin> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | g.schlisio, h.goebel, kdelibs-bugs, simonandric5, thomas.luebking, warthogdj |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Debian unstable | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=318904 | ||
Latest Commit: | Version Fixed In: |
Description
Vitaliy Filippov
2015-04-02 21:45:07 UTC
> How can it be possible?
A shortcut is the combination of the actual key and all currently activated modifiers (such as numlock)
To ensure the shortcuts work regardless of the numlock state, the shortcut is grabbed for both states.
Modmapping away numlock causes this to fail, because you turned the numlock keysym to 0x0
However, you'll still have numlock active (deactivate it and try again, you'll find global shortcuts operative as expected), so the generated shortcut event (by X11) does simply not match (wrong modifiers) the grabbed shortcuts.
The same problem applies to caps & scroll lock (in theory, since they're pretty much never active ;-)
=> kglobalaccel resp. KKeyServer would require a way to bypass XKeycodeToKeysym() to resolve the numlock modifier.
Interesting... But why disabling numlock keysym does change the modifier? I.e. doesn't the keysym just turn the modifier on/off, or is it included in the modifier code itself in some way? And it's not the same for CapsLock, I just checked it with the same experiment: I turned CapsLock ON, ran xmodmap -e "keycode 66 = ", checked Alt-Tab, Alt-F4, and they were working without any problem... (In reply to Vitaliy Filippov from comment #2) > Interesting... But why disabling numlock keysym does change the modifier? It doesn't. The keycode can no longer be resolved to the keysym and the numlock symbol (0x0) then not be effectively stripped from the event modifiers (which still carry the numlock flag), so the pressed shortcut is eg. "NumLock+Alt+Tab" (because numlock is still active) but the shortcut we're looking for is "Alt+Tab" and we failed to remove the "NumLock+" part (because we "believe" numlock is 0x0, rather than eg. 0xff7f) > And it's not the same for CapsLock Indeed - I took that idea from a comment in the kglobalaccel code (just actually looked up the numlock issue) I don't know the exact differences here (but 2nd + 3rd level shifted symbol resolution must be more complex anyway) Should I ever figure how to use the scroll lock key, i'd test that next ;-) Somewhere on my todo list is porting KKeyServer to use xkbcommon underneath. I'm delaying it as I'm kind of scared of breaking stuff. But my hope is that these situations will be way more clear and easier to handle. I don't think Xlib or xcb won't make a difference here, resolution will fail (unless xcb has some cool magic, like a default ;-) One could possibly say: if (g_modXNumLock) { // numlock not resolved. let's see whether it *might* be 0x10 - and hope for the best qWarning("KKeyServer, WARNING: the numlock modifier could not be resolved"); if (!((g_modXScrollLock|g_modXModeSwitch|g_alt_mask|g_meta_mask|g_super_mask|g_hyper_mask) & 0x10)) { qWarning("KKeyServer, WARNING: defaulting numlock modifier to 0x10, might be totally wrong"); g_modXNumLock = 0x10; } } btw, looking at cppkkeyserver__x11.cpp:560 // Check if meta overlaps with alt if (g_meta_mask | g_alt_mask) { that *really* looks like it should be if (g_meta_mask & g_alt_mask) { ??? my hope is that xkbcommon performs better mapping to keysyms and that these things just don't matter any more. I don't if this https://bugs.kde.org/show_bug.cgi?id=351992 is related but i tried changed xmodmap -e "keycode 77.." it does not make any change.. No, it's not related. This one fails because the numlock modifier symbol isn't resolvable. In return *no* shortcut will work (as we're looking for eg. Alt+F2 but get Numlock+Alt+F2 and cannot strip the numlock, as we don't know what key that is) It's a very certain setup, however you likely just killed your numlock as well by invoking that xmodmap call (and made your situation worse) *** Bug 318904 has been marked as a duplicate of this bug. *** Maybe you need to rething whether only filtering "exiting" lock states is the correct way. Maybe *all* lock states need to be filtered!? - If there is a lock-state, but there is no key for locking/unlocking this state, can this lock-state be meaningful at all? - If e.g the Caps-Lock state should be ignored, why would it be ignored only if there is a "CapsLock" key? - Is there any case where some lock-state is meaningful for kglobalaccel? - The X11 "level5_lock" (defined in /usr/share/X11/xkb/compat/level5 and used by the "de(neo)" layout) adds another lock-state. Should this be filtered, too? Why? Why not? - Assume this example: "Alt+3" is defined as a short-cut - Should "Shift+Alt+3" trigger this? According to [1] this would be the same as "Alt+§" (German layout) - Should "CapsLock+Alt+3" trigger this? According [1] CapsLock does not change the "3", so this would be the same as "Alt+3". - Should "ShiftLock+Alt+3" trigger this? According to [1] this would be the same as "Alt+§" (German layout) Now lets go on to the Numpad :-) - Should "NumLock+Alt+KP_3" trigger this? According to [1] this would be the same as "Alt+3". Now let's assume some Level-X-Lock, where "Level-X + ." gives the symbol "3" and "Level-X-Lock + ." gives the symbol "3", too. (This is what de(neo) does.) - Should "Level-X-Lock + Alt+." trigger this? To summarize: If all these cases would trigger the short-cut: Shouldn't all lock-state be ignored? [1] https://tronche.com/gui/x/xlib/input/keyboard-encoding.htm (In reply to h.goebel from comment #10) > Maybe *all* lock states need to be filtered!? The problem is not the lock, but the modifier. n-th level locks which "create different input" are another issue (see https://bugs.kde.org/show_bug.cgi?id=341959#c64) The problem about the modifier is that it cannot be resolved for filtering, see #3 and #5 in this bug for details. Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! With 5.76.0 I can not reproduce this issue. |