I have a couple keyboards with extra keys on them that weren't supported by the default install in Debian, so I decided to figure out how to get them working. Others have contributed info on their keyboards as well.
Jump to: HP nc40x0 | HP nc6000 | Compaq n620c | Compaq Wireless | Omnibooks | links | notes
This laptop has a few extra keys above the keyboard. This was the first one I played with and I'll use it to explain the process.
Left to right: Lock, Wireless, Presentation, Power, Mute, Volume Down, Volume Up. Also the combination of Fn+F8 is Battery. The Power button is dealt with via the BIOS and ACPI. The Wireless button is controlled by the bios and connects/disconnects the 802.11 and bluetooth wireless devices.
When I would push some of them I'd get something like the following in syslog,
Apr 16 00:56:40 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x8a on isa0060/serio0). Apr 16 00:56:40 localhost kernel: atkbd.c: Use 'setkeycodes e00a' to make it known.
Scott James Remnant explains,
setkeycodes e00a 152 # 'Lock' key to 'KEY_COFFEE' setkeycodes e008 148 # 'Presentation' key to 'KEY_PROG1' setkeycodes e009 149 # 'Battery' key (Fn+F8) to 'KEY_PROG2'
Those seemed like reasonable values to me and after running those commands I get events for those keys. The suggested rcS.d script would solve it per system, but ideally we'd have a way to solve it for anybody with this keyboard. The console-data package ships the of console keymaps, but doesn't seem to have keymaps for the "Internet" syle keyboards. Maybe it could be enhanced to support these types of keyboards? Another alternative would be a package for this keyboard (or laptop or whatever) that drops in either a keymap file or an init script with the above commands. If you have any ideas on how this should be solved for Debian let me know.
It's horribly confusing how this stuff works, as you'll see the numbers seemed to be randomly mapped. We can use showkey(1) from the console and xev from within X to gather more info.
| Key | syslog complaint | value set | showkey -s | showkey -k | X keycode |
| Lock | e00a | 152 | 0xe0 0x12 press 0xe0 0x91 release |
0x00 0x81 0x98 | 146 |
| Presentation | e008 | 148 | 0xe0 0x1f press 0xe0 0x9f release |
0x00 0x81 0x94 | 159 |
| Battery (Fn+F8) | e009 | 149 | 0xe0 0x1f press 0xe0 0x97 release |
0x00 0x81 0x95 | 151 |
| Mute | works | 0xe0 0x20 press 0xe0 0xa0 release |
0x71 0xf1 | 160 | |
| Volume Down | works | 0xe0 0x2e press 0xe0 0xae release |
0x72 0xf2 | 174 | |
| Volume Up | works | 0xe0 0x30 press 0xe0 0xb0 release |
0x73 0xf3 | 176 |
As you can see the kernel keycode is not directly related to the X keycode. It turns out there is a mapping table defined in linux/drivers/char/keyboard.c. The insanity is partly explained in this thread. Rather than try and understand why I will just accept that they are different and move on to getting things setup in X.
OK, now we can see the events in X. Using xev they look like,
KeyPress event, serial 22, synthetic NO, window 0x800001,
root 0x40, subw 0x0, time 38596, (87,88), root:(512,384),
state 0x0, keycode 146 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes: ""
Note the "NoSymbol". We can use xkb to associate symbols with those keycodes. This is useful because window managers and applications can take action based on symbols rather than keycodes, allowing them to perform certain actions generically without needing to know what actual key is used.
The xkb configuration files are stored at /etc/X11/xkb/. While these files are generated from the full X build, you can tweak them at runtime as long as you make all the right changes.
Here's some useful links for xkb,
Fortunately xkb already supports a bunch of these "Internet" keyboard extensions. I have created a runtime patch that associates some symbols with the keycodes we set above and the ones that were already working. Before applying it, you might want to backup the files it touches.
Download xkb-hpnc40x0.patch and apply in /etc/X11/ with 'cat xkb-hpnc40x0.patch |patch -p0'. If you're applying to the X server source the process is similar, but you won't need a few of the files since they are generated by by the build.
After applying the patch, you'll need to switch your X server config to use the newly defined model and restart the Xserver (as well as run the setkeycodes commands above). Mine looks like,
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "keyboard"
Option "CoreKeyboard"
Option "XkbRules" "xfree86"
Option "XkbModel" "hpnc40x0"
EndSection
After restarting the X server you can check that it's configured correctly by running setxkbmap -print. On my system,
xkb_keymap {
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc/pc(pc105)+pc/us+inet(hpnc40x0)" };
xkb_geometry { include "pc(pc104)" };
};
This model definition automatically includes the pc105 symbols too. Now that we know it's loaded we check with xev, and see that we now have symbols,
KeyRelease event, serial 22, synthetic NO, window 0x800001,
root 0x40, subw 0x0, time 90062691, (54,127), root:(479,423),
state 0x0, keycode 146 (keysym 0x1008ff8d, XF86Away), same_screen YES,
XLookupString gives 0 bytes: ""
I intend to file a wishlist bug with the above patch, but I want to get some feedback on it and determine if it applies to other HP models (which might cause me to change the model string and comments).
Now that X is setup there are several ways to associate actions with these keys.
Thanks to dannf for the picture and help testing. The "lock", "presentation", and "battery" are the same as the HP nc4010 above. The mute and volume up and volume down keys are on the front of the laptop and don't appear to generate keycodes. Maybe they are similar to the audio buttons found on the HP Omnibook 500 and 6000 models which are wired directly to the sound system and require sound driver support to get working?
Here's a patch for the HP nc6000. It just enables the three keys which are the same, and you'll need to use the above setkeycodes commands as well.
If anyone gets the audio keys working let me know.
Vlad Yasevich sent in a patch for the Compaq n620c. He thinks it may work for the n610c too. Like the other patches above, it has everything needed to apply to a system at runtime. If you are patching the server source you only need the files that the build doesn't autogenerate. If this patch works for you on different models, please let me know.
The extra keys on a bunch of HP Omnibook (and Pavillion branded versions of the Omnibooks) are supported by the omke project. This includes ob500, ob6000, obXE3, and a bunch of others. Once you get the keys visible then the generic notes above apply for setting up the keys in X.
Some of the Omnibooks, namely ob6000 and ob500, have separate keys for controlling audio and these are not normal keyboard keys, but connected directly to the sound chip and require support in the sound driver. Someone posted a patch to get them working.
There is a mailing list for Linux on Omnibooks here, this is the best place to ask omnibook related quesitons.
This is the keyboard that came with the wireless keyboard/mouse that integrates with the LCD display I got. On the back of the keyboard there are various part numbers, and FCC ID, and it's listed as "Model KBR0133".
There are 8 extra keys across the top, some generate errors in syslog, some work and show events in xev. The errors in syslog look like,
Apr 17 17:21:40 cyrix kernel: keyboard.c: can't emulate rawmode for keycode 242
| Key # from left | My name for the picture | result |
| 1 | info | syslog error, 242 |
| 2 | home | X keycode 130 |
| 3 | search | X keycode 122 |
| 4 | X keycode 236 | |
| 5 | group or chat | syslog error, 241 |
| 6 | presentation | syslog error, 240 |
| 7 | meeting | syslog error, 244 |
| 8 | news | syslog error, 243 |
I haven't spent time on getting this to work yet. I did notice that LinEAK lists support for a couple Compaq keyboards with 8 extra keys on them that are labeled the same as this model. Maybe that will help.
If you are reading this page and adding support for your funky keyboard, do the right thing and ensure that the support makes it upstream so that all users of all distros will benefit.
It would be cool if console-data and xserver-xfree86 debconf questions would ask if your keyboard has extra keys and then let you pick from a list. Somebody should do this. Maybe I should file wishlist bugs.
This page has a slight Debian bias but should be useful to all.