geekhack
geekhack Community => Keyboards => Topic started by: quadibloc on Tue, 08 September 2009, 22:58:06
-
It has been noted, on a page I learned about from this forum, that a 122-key keyboard behaves like an 84-key AT keyboard. And the keys that function like the function keys on a normal keyboard are the ten keys to the left of the main typing area, which work as F1 through F10.
Yet, if one compares the Scan Code Set 3 scan codes of the IBM standard Host Connected Keyboard with those of a 101-key keyboard, the function keys correspond to PF1 through PF12, and PF13 on the 122-key keyboard corresponds to Esc on a 101-key keyboard. So why aren't the keys interpreted this way?
The explanation is basically that a computer running in Windows doesn't know what to do with a keyboard that only outputs Scan Code Set 3. It pretends those scan codes are in Scan Code Set 2, and, luckily, the result is no worse than turning the keyboard into an 84-key keyboard.
But I also remember reading that Linux doesn't work well with some cheaper keyboards. This is because by default, it tries to use Scan Code Set 3 if available, and some cheaper keyboards claim to support that set when polled... but their implementations are flawed.
I suspect this means that a 122-key keyboard will have a different key mapping in Linux, one based on Scan Code Set 3 correspondences, than it would in Windows!
Also, since the expected behavior of a 122-key keyboard is to be operating in Scan Code Set 3, this means that building a keyboard that can just switch between 101-key with extra keys operation to 122-key standard operation through some Fn-key combination, as I thought would be nice, probably can't be achieved, since the type of keyboard has to be decided when the computer boots up. (Of course, sending the appropriate scan codes as Scan Code Set 2 scan codes might be enough to satisfy a terminal program expecting a Host Connected Keyboard, since presumably it would still go through the operating system...)
-
Haven't tried to plug in a 122-key terminal board on my machine but you should be able to get what you want with showkey -e and setkeycodes
showkey -e must be ran in a terminal not a XTerm window. After you start it just press any key and the scan code for the key will be shown. It should be noted that other key events will also be shown so you have to press a particular key a few times to see which piece of the stream is the key scan code.
Once you have the scan code you can use setkeycodes to map the scan code to a kernel keycode defined in /usr/include/linux/input.h
I used this to remap the dead keys on my Japanese keyboard.
NOTE: If you have X11 running and run setkeycodes to modify a key the X11 keyboard driver will hang. Use you mouse to logout which will reload X11 and you should now have your new key working in X11.
As far as using a key to switch from 101 mode with extra keys and 122 mode that is a little harder to do but can be done if you only want it in X11 that is. You just need to define a 122 key layout for the XKB extension and set them both up. Then define your layout modifier to the key you want to activate your alternate layout. I've been looking into this myself but have not had a chance to play with it yet.
-
Oh forgot to add to get any of the above to work you must get the kernel to register all of your keys first. X11 now uses the kernel keycodes to layout your keyboard. I have not had the time yet to dig into how this works yet but I will. Because I think I will need to know how it works to get some of the things I want to do on my Japanese keyboard.
-
The explanation is basically that a computer running in Windows doesn't know what to do with a keyboard that only outputs Scan Code Set 3. It pretends those scan codes are in Scan Code Set 2, and, luckily, the result is no worse than turning the keyboard into an 84-key keyboard.
I'm sure it isn't luck.
But I also remember reading that Linux doesn't work well with some cheaper keyboards. This is because by default, it tries to use Scan Code Set 3 if available, and some cheaper keyboards claim to support that set when polled... but their implementations are flawed.
I suspect this means that a 122-key keyboard will have a different key mapping in Linux, one based on Scan Code Set 3 correspondences, than it would in Windows!
But a 122-key terminal keyboard will reject commands to change the scancode set, so the driver, if it tried to switch to set 3, would decide it had been unsuccessful.
Looking at drivers/input/keyboard/atkbd.c in the Linux 2.6.30.6 source tree, it defaults to set 2. Set 3 has to be turned on with a module parameter -- though it is selected if you set the keyboard to return the identity AC A1 (Sun NCD PS/2).
In any case, I did my original tests on a 2.4 kernel, which appears to stick to set 2.