New manufacturing data flags for keyboards (2nd draft).
jg at laptop.org
Sun Oct 7 10:39:57 EDT 2007
On Sun, 2007-10-07 at 00:35 -0400, Albert Cahalan wrote:
> Re: New manufacturing data flags for keyboards (2nd draft).
> > Keyboard Layout KM KL KV Comment
> > USInternational_Keyboard olpc us olpc
> > OLPC_Argentina_Keyboard olpc es olpc (Spanish)
> > OLPC_Brasil_Keyboard olpc br olpc (Portuguese)
> > OLPC_Ethiopia_Keyboard olpc us,et olpc2,olpc
> > OLPC_Libya_Keyboard olpc us,ara olpc2,olpc (Arabic)
> > OLPC_Nigeria_Keyboard olpc ng olpc (for West Africa)
> > OLPC_Thailand_Keyboard olpc us,th olpc2,olpc
> > Urdu_Keyboard olpc us,ur olpc2,olpc
> > Cyrillic_Keyboard olpc us,ru olpc2,olpc
> > OLPC_Turkey_Keyboard olpc us,tr olpc2,olpc
> > OLPC_Nepal_Keyboard olpc us,np olpc2,olpc (Not final)
> > Mongolian_Keyboard olpc us,mo olpc2,olpc
> > Kazakhstan_Keyboard olpc us,kz olpc2,olpc
> It seems like you could just enumerate them, 0 to 12. If key
> shapes ever change, you can add a flag at that time.
An enumeration is ad-hoc, and then you have to maintain a table
mapping the enumeration to the X keyboard extension names.
This would require updating the distribution to update such a mapping,
rather than being able to leverage the much larger number of layouts
already in the Xkb database. With this scheme, we can introduce a new
layout at best, with no work at all, and at worst, by adding the
necessary xkb layout information.
> Supplying mapping data would be nice as well.
I don't know what you mean by mapping... Do you mean the data Xkb uses
to take keycodes and map them to characters?
> There needs to be a way to change this in case somebody swaps
> a keyboard or draws new characters on the keys. (something that
> would change what OpenFirmware uses, with low risk of bricking)
> Best would be something that works even with secure boot, but
> a simple OpenFirmware command would do for now.
Sure; though we'll have to be able to unlock the firmware, something we
have to be able to do in repair depots at times.
In any case, your xorg.conf can still override any defaults. What I
want is a system which "just works" in the default case without being
forced to mess with configuration files, as we do today.
> Locale needs to be separate from the keyboard, but machines
> should have nice defaults as they come from the factory.
> Default locale could go in the manufacturing data (separate
> from keyboard) or could be in the OS image. Just give it
> straight and simple: en_US.UTF8, es_AR.UTF8, etc.
Yeah, probably the best we can do. We'll still have to ask people to
select default language at first startup (or set it), as countries
which may be sharing the same keyboard may be using many different
languages. At most LANG can be a "hint" of the most likely correct.
> This looks about right:
> Keyboard number: manufacturing data
> Keyboard mapping data: manufacturing data
> Default locale: either manufacturing data or OS image
> Default timezone: either manufacturing data or OS image
> Radio restrictions: manufacturing data (for WLAN boot)
> Devel mailing list
> Devel at lists.laptop.org
One Laptop Per Child
More information about the Devel