New manufacturing data flags for keyboards (2nd draft).

[Mitch Bradley]

Jim's proposal solves the X problem, and I think we should adopt it.

We also have the problem of letting OFW and the Linux kernel know enough 
about the keyboard so developers can type US ASCII , which is the common 
subset that is sufficient for managing diagnostics, booting, and 
installation procedures.

One solution would be to include a lot of keymaps in OFW and select one 
based on the new KL tag.  However, I'm not keen on having to carry 
around a lot of keymaps in the ROM, and extend that list from time to time.

I would rather have another new tag whose value is a map from US ASCII 
characters to the scancode+shift_state that corresponds to that 
character's printed location on the keyboard.  The trivial encoding 
would be 9 bits per 7-bit US ASCII character - 7 bits for the scancode + 
2 bits for one of four printing positions, hence 144 bytes, which fits 
easily in a mfg data tag.

Note that I am explicitly and very intentionally limiting this to US 
ASCII.  The extension to arbitrary international characters is a can of 
worms that would scuttle the entire scheme.  This is just for 
booting/OFW/developer use.

I will submit a more concrete proposal describing exact encodings later 
this weekend.