On 10/7/07, Jim Gettys <[EMAIL PROTECTED]> 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) _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel