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

"commit to X.org" is a fine way to assign 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.
>
> That's not how Xkb works.  They do have value.  Layouts are for
> abstracted keys, that are not in a specific physical location.

I suppose it could work if you tolerate listing keys which don't
exist and you already added all XO-specific keys to some sort
of global list (meaning every PC now has a "mesh view" key
defined but missing from the physical keyboard)

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

Sure. Each can use a subset of the data.

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

Last I heard, countries were customizing the OS images anyway.
So you already have the country-specific SKUs AFAIK.

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

Definitely. It's a default.

Perhaps the initial activation should supply another default
that takes priority.

> > > > Default timezone: either manufacturing data or OS image
>
> No, doesn't make sense; OS image and control panel we plan to implement.

A kid in a small (east-west dimension) country should not need
to deal with setting the timezone.

For a large (east-west dimension) country, often most of the
kids are in one timezone.

> > > > Radio restrictions: manufacturing data (for WLAN boot)
>
> No, radio channel information is in the wireless module, as I remember.
> It has its own flash.

If you got rid of that flash, you'd:

1. save money on the flash
2. simplify inventory