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

[Albert Cahalan]

On 10/7/07, Jim Gettys <jg at laptop.org> wrote:
> On Sun, 2007-10-07 at 00:35 -0400, Albert Cahalan wrote:

> > 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.

As with anything else less than supplying a machine-readable
description of the full thing. Unless you change X, it just won't
know anything.

Two-letter codes are in some ways worse than simple numbers
because people will tend to forget that the codes are arbitrary.
Any way you do this, you're assigning arbitrary values.

> 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.

Those layouts are nearly worthless because they do not match
the XO keyboards.

> > 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?

I mean data suitable for mapping keycodes to characters
everywhere (OpenFirmware, Linux console, X).

> > 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.

Ideally the firmware would allow changing certain things without
being unlocked. (everything that doesn't help break anti-theft)

> 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.

Heh. Did that, and lost Alt-Ctrl-Fn-1 ability.

> > 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 is why the firmware should supply a separate setting
for the default locale. Default locale is directly associated
with a geographic region, not a keyboard.

> > 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)