The sorry state of keyboard interfaces (by alaric)
Back in the Dark Ages, keyboards were simple devices. Putting too much processing power in them would raise the cost unacceptably; they were kept as simple devices that told the host computer when buttons were pressed and released, and the host computer had the job of converting that into meaningful information such as entered data or commands.
In particular, keyboards didn't even know what was printed on their buttons. They told the computer what button was pressed as a "scan code", which was loosely tied to the key's position on the keyboard. Keyboards for different alphabets had different things printed on the keys, but generated the same scan codes regardless; the computer had to be told what "keyboard map" to use to convert those scan codes into letters.
This wasn't a big deal in the days of the original PC and AT keyboard interfaces, and the later PS/2 interface, where only one keyboard could be plugged into a computer; telling the computer what kind of keyboard you had wasn't a big deal.
However, by the time USB came to be, micro-controllers were sufficiently cheap that one capable of managing the USB interface to a keyboard would easily have been able to manage its own mapping to a standard set of codes based on what the key did rather than where on the keyboard it was, avoiding the need for keyboard maps. But, they didn't. Oh no. Instead, they standardised a new set of scan codes for the positions of keys on a "standard layout", regardless of what was printed on them. And of course, keyboards that don't follow the standard layout (such as compact laptop keyboards, or ergonomic ones, or keyboard emulators such as chorders) generate the scan codes for keys based on where they would be in a standard layout, meaning that the scan codes aren't really relating to anything sensible at all.
And meaning that we still need keyboard maps on the computers.
This becomes a real pain when you have more than one keyboard, which is easily done with USB - and is increasingly becoming the norm, as a laptop (with its own keyboard) is used as a desktop computer (with a nicer, external, keyboard). For a while I was using an Apple laptop, but mainly as a VM host for a NetBSD VM. The Apple laptop had an Apple keyboard, but I plugged in a USB PC keyboard. When using Mac OS software outside my VM, the laptop had the correct keymap but the external keyboard did not; when using my VM, it was the other way around. The situation sucked.
Also, I'm sure people who work with multiple languages would love to have multiple keyboards that they can switch between easily depending on what language they're typing, without having to reconfigure their keyboard map when they do so. As a nerd, I would love to be able to buy a small keypad covered in extra function keys and have it work alongside my normal keyboard (maybe even foot pedals!). How about specialist keyboards with function keys for tasks like computed-aided design?
So, here's my proposal: keyboards should identify their buttons with Unicode strings, and a type flag (glyph or function), and an optional position flag for duplicated keys (chosen from nine options: top left, top middle, top right, center, etc; a tenth value can be used for non-duplicated keys). When you press a key with "H" printed on it, the keyboard should say "glyph H is down". When you press the left shift key, the keyboard should say "function shift (bottom left) is down".
Keys with more than one glyph printed on them, corresponding to what should happen when that key is pressed with combinations of modifier keys, can be handled by the keyboard also providing a "modifier table". If I press shift+5 in the hope of getting the % sign printed above 5 on my keyboard, the keyboard should note that a shift key is pressed, then that 5 is pressed; but the modifier table should note that the keyboard's key caps will be giving the user the impression that this combination should produce a "%".
Function keys can be given any name, including useful keys such as "help", "cut", "copy", and "paste". And you can have as many soft-bindable F-keys as you want. All these rich function names can be passed through to software as-is, letting apps bind functionality to appropriately-named keys; to make this easier, there should be a shared vocabulary of function key names to avoid synonyms cropping up.
This would be easy to implement.
This would make keyboards plug-and-play.
This would make it easy to use multiple keyboards on the same computer.
This would open up new markets for keyboards with heaps of special function keys.
This could be done in a backwards-compatible manner by making keyboards expose the old USB scancodes by default, along with a note that they can be switched into Sensible Mode if the host computer supports it.
Lobby the USB implementors forum to put this into the next version of the USB HID specification now!
Thu 26th Apr 2012 12:34 pm 
Subscribe
By Maurice Snell, Sat 28th Apr 2012 @ 5:32 pm
Yes please - I'll buy that.
By Phil Stewart, Sun 29th Apr 2012 @ 8:30 pm
Good call. Not one I tend to think about too much, but it's definitely one of those issues that's all the more irritating when I do run in to it because it should be a completely solved problem already.
By angie (mum), Sun 6th May 2012 @ 12:01 am
Yes please make it happen. More years ago than I care to remember I worked as a Brook Street temporary secretary which meant I moved from office to office where required. Different makes of typewriter had their £, %, !, etc all in different places and were the bain of my life. To be able to give instruction to the machine to rationalise the keyboard and have how I wanted it would have been wonderful. Alaric make it happen.