Bug 345816 - Remapping Num Lock with xmodmap breaks all Alt+* key shortcuts in KDE! O_OOO
Summary: Remapping Num Lock with xmodmap breaks all Alt+* key shortcuts in KDE! O_OOO
Status: RESOLVED WORKSFORME
Alias: None
Product: frameworks-kglobalaccel
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: Martin Flöser
URL:
Keywords:
: 318904 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-04-02 21:45 UTC by Vitaliy Filippov
Modified: 2022-11-05 16:19 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vitaliy Filippov 2015-04-02 21:45:07 UTC
Hi!
I've just tried to disable NumLock by remapping it to nothing with xmodmap (xmodmap -e "keycode 77 =") and discovered that it breaks ALL Alt+* and Fn+* key shortcuts in KDE!!! I.e. Alt-Tab, Alt-F4 and so on stop working as usual: they don't close or switch windows anymore, but instead they are translated as is into the application, for example into Konsole.
I've double checked with xev - keycodes for Alt, F4, Tab and so on remain unchanged after remapping NumLock, and remapping other keys (for example Caps Lock or any other) doesn't affect Alt-* or Fn-* shortcuts.
How can it be possible?????? O_Ooo
Can you fix it please?

Reproducible: Always

Steps to Reproduce:
1. Execute command: xmodmap -e "keycode 77 ="
2. Press Alt-Tab or Alt-F4; look how nothing happens
3. Execute command: xmodmap -e "keycode 77 = Num_Lock"
4. Press Alt-Tab or Alt-F4 and discover they're working again


Expected Results:  
Remapping NumLock should not affect any global shortcuts in KWin or everywhere else.
Comment 1 Thomas Lübking 2015-04-02 22:27:42 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.
Comment 2 Vitaliy Filippov 2015-04-03 18:42:33 UTC
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...
Comment 3 Thomas Lübking 2015-04-03 19:08:19 UTC
(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 ;-)
Comment 4 Martin Flöser 2015-04-04 07:29:20 UTC
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.
Comment 5 Thomas Lübking 2015-04-04 08:51:13 UTC
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) {

???
Comment 6 Martin Flöser 2015-04-04 09:37:53 UTC
my hope is that xkbcommon performs better mapping to keysyms and that these things just don't matter any more.
Comment 7 warthogdj 2015-08-30 10:25:48 UTC
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..
Comment 8 Thomas Lübking 2015-08-30 11:57:42 UTC
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)
Comment 9 Thomas Lübking 2016-06-13 12:38:34 UTC
*** Bug 318904 has been marked as a duplicate of this bug. ***
Comment 10 h.goebel 2016-06-17 10:23:59 UTC
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
Comment 11 Thomas Lübking 2016-06-17 11:46:19 UTC
(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.
Comment 12 Justin Zobel 2022-10-21 23:59:53 UTC
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!
Comment 13 Bug Janitor Service 2022-11-05 05:07:48 UTC
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!
Comment 14 h.goebel 2022-11-05 15:56:06 UTC
With 5.76.0 I can not reproduce this issue.