Comment 16 for 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.)