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

[Jim Gettys]

On Sun, 2007-10-07 at 13:18 -0400, Albert Cahalan wrote:
> 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.

They are not arbitrary, and they are already in widespread us in the X
Window System, and are typically related to ISO country codes.

I am not about to add "yet another arbitrary registry" to the world.
Been there, done that, many times; experience is you only do so if you
must because there is nothing sensible you can use.  In this case, we
have a perfectly reasonable one, that is fully extensible; better yet,
with implicit registration (commit to X.org).

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

That's not how Xkb works.  They do have value.  Layouts are for
abstracted keys, that are not in a specific physical location.

"Any problem in computer science can be solved with another level of
indirection." - Roger Needham.  

If you want details, you can spend a day or three groking the complexity
that is Xkb.

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

The needs are different at different levels: OFW only needs ascii, Linux
console likes a bit more: at the X level, you have the complexity of
multiple keyboard layouts simultaneously with arbitrary character sets.
And we certainly aren't going to teach OFW or the Linux kernel the full
complexity for multiple layout support.

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

Could be: we can add a UI for modification of these strings later if it
happens often enough in the field to be worth it.  Right now, I'm mostly
interested in defining them so that they get set during manufacturing to
correct values.

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

Understand there is a cost associated with each individual SKU (part
number describing a particular variant), in terms of stocking.  So I
expect the identical SKU may often go to many different geographical
places where many different languages are spoken; any that share a
common keyboard.

So language locale can at most  be a "hint", it cannot be depended on,
or you have to stock more variants.

> 
> > > This looks about right:
> > >
> > > Keyboard number: manufacturing data
> > > Keyboard mapping data: manufacturing data
> > > Default locale: either manufacturing data or OS image

Locale is at most a hint.

> > > Default timezone: either manufacturing data or OS image

No, doesn't make sense; OS image and control panel we plan to implement.

> > > Radio restrictions: manufacturing data (for WLAN boot)

No, radio channel information is in the wireless module, as I remember.
It has its own flash.
                                - Jim


-- 
Jim Gettys
One Laptop Per Child