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. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel