You're right that both current methods work by sending a code back to the host, and that the host then decides how to interpret that code. The difference between the current state of affairs and what I'm suggesting has to do with two things: modifier keys and non-"standard" keys.
In my first example, I showed that the only way to produce an exclamation point is to send to the host both a shift and a one. That is, there are certain characters that by convention are intimately tied to other characters with the use of the shift modifier. This connection is arbitrary and makes it difficult to make a fully remappable keyboard in firmware.
The other thing is how to produce non-standard characters. This means international characters such as é, œ and special characters such as math symbols. For these characters, there is no standard at all. There are different conventions depending on the language and the OS.
Both of these problems can be solved with the same solution, a solution with two main approaches: make a dumb keyboard with a smart driver, or a smart keyboard with a dumb driver. This is what I'm interested in discussing.
I skimmed this thread the first time, so I may be making a couple of points that were well expressed already - apologies to the original authors.
DMG: So, as you are asserting - and I surely agree, the current crop of HID specs for keyboards define way to set codes representing keys, rather than say, characters.
It seems clear to me that the keyboard really _must_ have this functionality, at a minimum, for it to be useful for more than generating a sequence of unicode characters. Taking gamers and those who are wanting to remap ctrl and caps as simple examples: one wants to be able to represent the state of keys, rather than just events.
But - I'm not saying that a keyboard should not be able to send events. HID kbs already do for certain situations (errors, amusingly), but just not for keys.
So - if there were a way to describe, say, unicode mappings to a key event, and if the HID were extended to support this, then one could get more general semantic mappings sent reliably to different computers, say macs, and windows, in particular - linux, well - we can write the drivers for that easily.
So, given that drivers are much easier to write than firmware, and that config files are much easier to write and store on computers than firmware... the question for me is to find the edge cases that drive our motivation to consider stuffing the decode into firmware.
Roughly speaking, it is straightforward to write additional linux driver
layers and to map keys to arbitrary commands : e.g. generate this unicode when I hit this key, when in this state.
Under windows, it is less simple, and I can't say I enjoy it, but drivers are still more manageable as they get large... mumble, signing, installation notwithstanding.
On a mac, the driver situation is more irritating still, my understanding (please correct me, on the workarounds, I know there are some) is that one must submit the device to apple and apple will largely distribute drivers for it instead of the drivers coming with the device.
Immediately a couple've issues begin to motivate ourselves to explore the firmware option again. First, multi-OS support, bringing one's keyboard to work, a friend's and to one's home workstation or entertainment centre is a lot more possible (folks want to do each of these, not me.. other folks) if we don't need to install drivers onto each one when we attempt the attach. Secondly, Open Source drivers are much more irritating to distribute for mac and 64 bit windows due to signing and licensing constraints. Finally, not having to write and QA a different set of drivers for each version of each device and OS release that is desired to be supported is kinda nice.
The biggest 'gotcha', of course, is that there is not a widely supported HID definition to allow one to send arbitrary unicode to the Host.
With Windows and Linux, if you build a driverless device that conforms to the spec, future versions will often be more than willing to support it _for you_, especially if it is an 'oddball case' that makes heavy use of some interesting feature. If it requires drivers, you can kiss that happenstance goodbye without re-certification.
Apple doesn't support backwards compatibility with their own hardware, nevermind other folks'.
Just sayin', heh.
So - At this juncture, and for the forseeable future that a well-made device might be in use, I do lean towards getting as much into the firmware as on can manage. The device being able to flash itself from a file on a card, rather than requiring OS support, is nice - though it could also surface a tiny FS for the OS to write firmware files to.
It is an interesting question - but you'll notice that the vast majority of coders here have gone the firmware route, just as soon as they could manage it. The PS2 terminal boards under windows case being one of the oddball exceptions where firmware was not very viable, so a driver solution was attempted. Mind, I am _not_ happy with this state of affairs, and am working on the PS2->USB HID source again (for the teensy, USBkey, etc... and compatible)
As far as a non-HID device, goes... well, that is the driver option. Might as well support the basic HID in hardware anyway, then put the rest of the goo into pass-through and hook drivers so at least the effort for each platform will be sane, albeit still high. Extra state can be exposed through the HID, still. It will merely require a bit of driver to catch it. Wont need to be a _kernel_ driver, though, so user mode drivers and programs can do the deed on most platforms. With luck, backwards compatibility will reduce the churn on rewriting the thing. Personally, I hope not to find a reason to do this, but I have terminal boards... the urge to _fill_ the thing with weird hardware and clean up my desk is tempting... it has so much space inside, and steel armor... mmmm
thanks,
dfj
PS: the PS2->USB is my current 'main project' so it should be up in a rough form soon. First for the USB avrs, then hopefully for some of the others.