Turn on NumLock, verify the behavior by pressing the numpad digits. Change layout by executing a "setxkbmap us" or similar command. Verify that numpad digits still work as expected. Press and release any of the modifiers, e.g. left shift. Press the numpad keys and figure out that they're in a broken inconsistent state that should never occur. Numpad 5 inserts a literal 5 into applications, whereas the rest work as if NumLock had been turned off. numlockx reports it is switched on. Press the NumLock key and it's turned off, press again and it's turned on correctly. Expected behavior: changing layout should of course not effect numlock's state. Originally reported at https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1247668.
When NumLock is off, my numpad keys report keycodes 110-119 (with the exception of '5' which still has the keycode 84). E.g. in "xev", numpad '1' reports 115 End, instead of the expected 87 KP_End. (With NumLock on, it is 87 KP_1, as expected.) Speaking in terms of "xmodmap -pke" format, apparently the correct column is looked up (depending on NumLock's status), but in the wrong row for some reason (the row also depends on NumLock's status, though it shouldn't). Holding down the Fn key toggles the keycodes, i.e. with NumLock off it becomes 87 KP_End, and with NumLock on it becomes 115 End. The very same behavior is observable with "showkey" on the text console (with an offset of 8 in the key codes, and NumLock can't be toggled while showkey is running). Apparently, this laptop works differently than most laptops, and probably the hardware does some magic that it really shouldn't do. The commands "numlockx on" / "numlockx off" work as expected, they apparently somehow tell the hardware whether to alter the keycodes consistently with X's belief. Using "xmodmap -pke"'s terminology, the row and the column are switched together, and I haven't found a way to get to the other two row/column combos. This suggests that theoretically there should exist a workaround. Whenever X's belief of the NumLock state changes, it should do whatever "numlockx off" does to lie to the hardware so that it doesn't modify the keycodes. This is a Samsung NP300E5Z laptop. (By the way, it doesn't have a NumLock LED.)
A few people confirmed that their system always sends keycode 87 for keypad 1/End, independently of NumLock's state. They don't face this bug. I've connected an external keyboard to my laptop and that one also always sends 87, as opposed to the built-in one. Really looks like we're facing some broken keyboards. Anyway, X's behavior is still not reasonable. When NumLock is on, changing the layout and then pressing a modifier shouldn't trigger the keyboard's brain-damaged "geez, NumLock went off, let me alter the keycodes" mode, since NumLock didn't turn off at all.
Created attachment 98637 [details] [review] Works for me, probably not the proper solution though Here's a workaround patch that I've been using successfully for a while. Upon loading a new keymap, Xkb does something with the locks. I'm not sure what it is and why it would do so. I just commented out that part and it works great for me. There might be side effects unbeknownst to me. Apparently various manufacturers create keyboards that change the keycode of the numpad keys to their non-numpad equivalents when NumLock is off. Crazy, I know. This is an issue Xkb developers should be aware of. The current behavior on layout change is still not reasonable at all, it's a bug somewhere in Xkb, triggered by such keyboards. Nevertheless, this bug should be fixed.
Guys, the problem still happens on various linux distros in 2016. Is there anybody looking into this? It's so annoying for anybody using more than one keyboard layout.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/261.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.