I don't know about just enumerating them, but the naming scheme seems a bit ad hoc. Even though X windows assigns kb symbol tables by country code, I would suggest we use the language name for the keyboard itself, e.g., es, pt, etc. with the ability to add qualifiers, such as es_AR. Also, we will undoubtedly have many more keyboards over time. That said, the plan for keyboards with non-Latin scripts is to also have the Latin, so at the OFW level, that mapping will always work. The tricky one is for keyboards that introduce variants on the Latin layout, such as Spanish and Portuguese. These latter changes are generally pretty small, so there may be a compact "diff" way of specifying them, saving Mitch some space.
<br><br>-walter<br><br><div><span class="gmail_quote">On 10/7/07, <b class="gmail_sendername">Albert Cahalan</b> <<a href="mailto:acahalan@gmail.com">acahalan@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Re: New manufacturing data flags for keyboards (2nd draft).<br><br>> Keyboard Layout KM KL KV Comment<br>> USInternational_Keyboard olpc us olpc<br>> OLPC_Argentina_Keyboard olpc es olpc (Spanish)
<br>> OLPC_Brasil_Keyboard olpc br olpc (Portuguese)<br>> OLPC_Ethiopia_Keyboard olpc us,et olpc2,olpc<br>> OLPC_Libya_Keyboard olpc us,ara olpc2,olpc (Arabic)<br>> OLPC_Nigeria_Keyboard olpc ng olpc (for West Africa)
<br>> OLPC_Thailand_Keyboard olpc us,th olpc2,olpc<br>> Urdu_Keyboard olpc us,ur olpc2,olpc<br>> Cyrillic_Keyboard olpc us,ru olpc2,olpc<br>> OLPC_Turkey_Keyboard olpc us,tr olpc2,olpc
<br>> OLPC_Nepal_Keyboard olpc us,np olpc2,olpc (Not final)<br>> Mongolian_Keyboard olpc us,mo olpc2,olpc<br>> Kazakhstan_Keyboard olpc us,kz olpc2,olpc<br><br>It seems like you could just enumerate them, 0 to 12. If key
<br>shapes ever change, you can add a flag at that time.<br><br>Supplying mapping data would be nice as well.<br><br>There needs to be a way to change this in case somebody swaps<br>a keyboard or draws new characters on the keys. (something that
<br>would change what OpenFirmware uses, with low risk of bricking)<br>Best would be something that works even with secure boot, but<br>a simple OpenFirmware command would do for now.<br><br>Locale needs to be separate from the keyboard, but machines
<br>should have nice defaults as they come from the factory.<br>Default locale could go in the manufacturing data (separate<br>from keyboard) or could be in the OS image. Just give it<br>straight and simple: en_US.UTF8, es_AR.UTF8, etc.
<br><br>This looks about right:<br><br>Keyboard number: manufacturing data<br>Keyboard mapping data: manufacturing data<br>Default locale: either manufacturing data or OS image<br>Default timezone: either manufacturing data or OS image
<br>Radio restrictions: manufacturing data (for WLAN boot)<br>_______________________________________________<br>Devel mailing list<br><a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br><a href="http://lists.laptop.org/listinfo/devel">
http://lists.laptop.org/listinfo/devel</a><br></blockquote></div><br><br clear="all"><br>-- <br>Walter Bender<br>One Laptop per Child<br><a href="http://laptop.org">http://laptop.org</a>