Hi all, As I already mentioned in my Fedora 8 ideas mail, one of the things I've been thinking about and also actively working on is getting easy access / internet keys to work out of the box (keys like volume up / down, play, homepage, email, etc). From now on this mail will reference these keys as "extra" keys. Actually most parts are already there and its just a matter of properly configuring things for the most part. In the next part of this mail I'll first describe the problem, then how things used to work under the Linux 2.4 kernel, currently don't work under the 2.6 kernel, and how the situation should be under the 2.6 kernel to make things work even better then they did under 2.4 . Then I'll propose a number of changes to various configurations to make this reality. 2 Problems ---------- There are 2 problems, the big problem is that when these extra keys started showing ups on ps/2 keyboards, manufacturers didn't create a standard, but instead everyone decided on itself which still free scancodes to use for which key. Since one cannot detect which brand/model ps/2 keyboard is connected, this means that the user will always need to configure this through some kinda gui. Luckily Microsoft has published a document in which they advice which scancodes to use for which extra keys, not only their own keyboards use these scancodes, but since windows will work with these out of the box, also most newer ps/2 keyboards from other manufacturers follow this. The 2.6 kernel assumes a microsoft compatible keyboard by default, so with such a keyboards things should just work (but they don't, see below). The other problem is that the scancodes from a keyboard pass through many layers of translation before reaching an X (GNOME/KDE) app, more on this below. The 2.4 kernel days ------------------- Unlike the 2.6 kernel, the 2.4 kernel didn't do any translation on scancodes, sending them directly to X. For some time X didn't know what todo with these and special tools like lineak were needed to be able to use these keys. Later Stanislav Brabec (from SUSE) translated all the available lineak configs to /usr/share/X11/xkb/symbols/inet, allowing one to select a keyboard model of for example "compaq armada laptop" or "microsoft wireless internet /keyboard". He also created special X-keysyms like XF86HomePage for these keys. So when a user now selected the correct keyboard model (through GNOME / KDE keyboards preferences for example) X would generate these special X-keysyms for his special keys. The user then only needed to configure apps to recognise these, through for example his window-manager shortcut keys configuration. The 2.6 kernel days ------------------- The 2.6 kernel brought a new input subsystem with it. This subsystem no longer thinks in scancodes, but rather thinks in keycodes, which are defined in /usr/include/linux/input.h . This is a good thing, as for example USB keyboards do not have scancodes and USB keyboards do have a real standard for extra keys, allowing the kernel to always send the correct keycode for an extra key. For ps/2 keyboards the kernel translates the scancodes from the ps/2 keyboard to keycodes, assuming microsoft compatible scancodes for extra keys by default. This can be changed by using setkeycode. However many apps, including Xorg as it is currently configured under Fedora, still think in scancodes. For these applications the kernel will translate the keycodes it internally uses back to scancodes, using a fixed (non configurable) translation model generating microsoft compatible scancodes for extra keys. An example of how things used to be and are now ----------------------------------------------- On my Compaq N600c laptop I have 4 extra keys, below is a table, with the Icon's on the key, the scancode's generated and the X-keysym's generated when using a 2.4 kernel and selecting "Compaq armada laptop" as keyboard model in X: Icon on key Scancode X-keysym I(nternet) e0 23 XF86WWW Mail e0 1e XF86Mail Home e0 1f XF86HomePage Looking Glass e0 1a XF86Search When I use this laptop with the 2.6 kernel, whenever I press one of the 4 keys, the following messages show up in dmesg (and nothing happens): atkbd.c: Unknown key pressed (translated set 2, code 0x9f on isa0060/serio0). atkbd.c: Use 'setkeycodes e01f ' to make it known. This happens because the scancodes send by the extra keys on my laptop are not part of the microsoft compatible set of scancodes, and thus the kernel does not have a default scancode -> keycode translation for them. Thus I issue setkeycodes command for all 4 keys on my laptop. However, remember how X will now get fake scancodes, which are made by translating the internal keycodes to microsoft compatible scancodes, this results in the following happening: Icon on key Scancode Linux keycode Fake scancode received by X I(nternet) e0 23 150 / KEY_WWW e0 02 Mail e0 1e 155 / KEY_MAIL e0 6c Home e0 1f 172 / KEY_HOMEPAGE e0 32 Looking Glass e0 1a 217 / KEY_SEARCH e0 e5 Notice how X now receives scancodes which are very much DIFFERENT from the real scancodes !! This can be worked around by telling the kernel to skip the double translation steps for ps/2 keyboards, by setting the softraw sysfs attribute of the atkbd input device to 0. However this is frowned upon by the upstream kernel input system maintainers, and they will NOT change the default for softraw from 1 to 0, thus I believe we shouldn't either. There are also good technical reasons not todo this. What if I'm using softraw 0 and plugin an USB-keyboard, that will then still send microsoft compatible fake scancodes (there is no softraw for USB keyboards, as the don't have real scancodes, only fake ones). Which will cause X to receive 2 different sets of scancodes for the same key. What if I plugin USB speakers, if those speakers have volume buttons, those will also show up as a "keyboard" with extra keys using microsoft compatible fake scancodes. The solution ------------ Actually although thinks look worse with the 2.6 kernel at a first glance, things are actually better. Since X now sees only fake scancodes, always emulating microsoft compatible extra keys, things become much easier. All we need todo is to teach X (through xkb configuration) that the keyboard it now sees is not just a 105 key generic keyboard, but a 105 key generic keyboard with microsoft compatible extra keys. When X has been thought this (and apps configured to recognise the special X-keysyms) USB devices and microsoft compatible (iow most) keyboards, will just work. The only problem is non-microsoft compatible ps/2 keyboards, like the extra keys on my laptop, for those setkeycodes will need to be run. We need to write some sort of new configtool for this, allowing people to select from a premade list of keyboard configs, and if necessary to create there own config key by key, all nice gui based ofcourse. The plan / todo --------------- 1) Fix the kernel to be 100% consist with microsoft compat keyboards in ps/2 versus USB connection. -The kernel currently sends KEY_FIND for the looking glass key when connected through USB, where as this key gets mapped to KEY_SEARCH when connected through ps/2. This is because of a bug in the USB mapping where it deviates from the USB HUT standard, a patch has been send and merged for this upstream -The kernel currently sends KEY_WWW for the key with the Home icon when connected through ps/2, in the USB case it correctly sends KEY_HOMEPAGE a patch has been send upstream for this. Upstream has agreed that this is correct, but not yet merged the patch (AFAIK). 2) Modify /usr/share/X11/xkb/symbols/pc, to recognise the microsoft compatible scancodes* for extra keys, as part of the generic 104 key and generic 105 key keyboard models. Doing it this way means that people who have not changed the keyboard model from the default will automatically get these X-keysym mappings, without requiring any magic to change xorg.conf. Also people who have choicen a different model (and thus possibly are using softraw = 0), will not be affected by the new mappings this way, avoiding any regressions for people who have already made configuration changes themselves to get things to work. -I'm working on a patch for this and will a file a BZ ticket with this patch soon. Note: Stanislav Brabec who created /usr/share/X11/xkb/symbols/inet is currently working on an xkb patch which will create a virtual linux keyboard model. However his works assumes using the evdev driver of xorg, which we currently don't (I don't know if there are plans for this), and his work is much more invasive, also its unknown if this will be ready for F8-test2 . * the X internal keycodes for the scancodes actually, but thats a technicallity not important for this discussion. 3) Teach apps about the extra keys X-keysyms. For example metacity has actions which can be bound to hotkeys for many of the things for which keyboards have extra keys, but the default bindings for these keys are empty, instead of being bound to the extra keys X-keysyms by default. I'll create BZ tickets for atleast metacity and possibly patches too, but thats not going to happen the coming week, help with this would be much appreciated. Regards, Hans