Re: New manufacturing data flags for keyboards (2nd draft).
The proposal for the ASCII keyboard map is detailed in: http://wiki.laptop.org/go/Manufacturing_Data#Keyboard_ASCII_Map In the process, I extended the tag format in an upward-compatible fashion to allow value strings longer than 127 bytes: http://wiki.laptop.org/go/Manufacturing_Data#Data_Format I have implemented support for that new format, with full interoperability with the old short format, in a test version of the firmware. I plan to write a program that will automatically create an image of the new KA tag from the master spreadsheets that define the OLPC keyboard layouts. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
Kim Quirk wrote: Mitch, We probably should plan to get these new tags into the 50 unit MP Pre-build as well. Do you agree? Yes. That will require a different firmware. I am working on the change package now - new firmware plus a kit of tag values for specific keyboards. Kim On 10/8/07, *Mitch Bradley* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The proposal for the ASCII keyboard map is detailed in: http://wiki.laptop.org/go/Manufacturing_Data#Keyboard_ASCII_Map In the process, I extended the tag format in an upward-compatible fashion to allow value strings longer than 127 bytes: http://wiki.laptop.org/go/Manufacturing_Data#Data_Format I have implemented support for that new format, with full interoperability with the old short format, in a test version of the firmware. I plan to write a program that will automatically create an image of the new KA tag from the master spreadsheets that define the OLPC keyboard layouts. ___ Devel mailing list Devel@lists.laptop.org mailto:Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
On 10/7/07, Jim Gettys [EMAIL PROTECTED] wrote: 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. We already have this: the secure boot capability will happily launch signed olpc.fth scripts (although with some issues, see trac bug #3582.) We can easily generate and distributed signed images which will alter some mfg-data property, run diagnostics, or even generate simple UI. Of course, these will need to be carefully audited to ensure they are secure; also see trac #4101. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
I don't know about just enumerating them, but the naming scheme seems a bit ad hoc. Even though X windows assigns kb symbol tables by country code, I would suggest we use the language name for the keyboard itself, e.g., es, pt, etc. with the ability to add qualifiers, such as es_AR. Also, we will undoubtedly have many more keyboards over time. That said, the plan for keyboards with non-Latin scripts is to also have the Latin, so at the OFW level, that mapping will always work. The tricky one is for keyboards that introduce variants on the Latin layout, such as Spanish and Portuguese. These latter changes are generally pretty small, so there may be a compact diff way of specifying them, saving Mitch some space. -walter On 10/7/07, Albert Cahalan [EMAIL PROTECTED] wrote: Re: New manufacturing data flags for keyboards (2nd draft). Keyboard Layout KMKL 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_Keyboardolpc ng olpc(for West Africa) OLPC_Thailand_Keyboard olpc us,th olpc2,olpc Urdu_Keyboardolpc us,ur olpc2,olpc Cyrillic_Keyboardolpc 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. Supplying mapping data would be nice as well. 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. 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. 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 -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
On Sun, 2007-10-07 at 00:35 -0400, Albert Cahalan wrote: Re: New manufacturing data flags for keyboards (2nd draft). Keyboard Layout KMKL 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_Keyboardolpc ng olpc(for West Africa) OLPC_Thailand_Keyboard olpc us,th olpc2,olpc Urdu_Keyboardolpc us,ur olpc2,olpc Cyrillic_Keyboardolpc 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@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
Seems like we should do it to me. Bernie, keep in mind that support questions come at a cost too. It is often worth fixing something despite easy work around just to not have to answer the same question again and again Now, if we were commercial software, with a 900 number and everyone's names, email addresses, and phone numbers carefully hidden, so we made money every time someone called the 900 number, we might have a different point of view... Reminds me of certain large companies I know... Note the suggestion to fix it comes from the person who has to ultimately answer said questions. - Jim On Sat, 2007-10-06 at 17:03 -1000, Mitch Bradley wrote: Bernardo Innocenti wrote: Mitch Bradley wrote: One solution would be to include a lot of keymaps in OFW and select one based on the new KL tag. However, I'm not keen on having to carry around a lot of keymaps in the ROM, and extend that list from time to time. There's also a trivial, good enough solution to the problem: don't do anything. All non-US computer users like me have learned to live with it, and it's not as bad as it may seem to US users. In Italian, French and German layouts, there are typically just a few misplaced keys you need to care about... and those you don't remember are easy to find by trial and error. Really, if it's just for system recovery tasks, then it's just for techies. And if they're technical enough to type shell and forth commands, they're also going to understand the issue rather than complain my keys are messed up, I'm lost!. I have two complaints in the last two days from techies. -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
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
Re: New manufacturing data flags for keyboards (2nd draft).
On Sun, 2007-10-07 at 13:18 -0400, Albert Cahalan wrote: 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. 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
Re: New manufacturing data flags for keyboards (2nd draft).
On 10/07/2007 10:45 AM, Jim Gettys wrote: Seems like we should do it to me. Agreed. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
(adding devel@ to cc) Mitch Bradley wrote: Jim Gettys wrote: What are the olpc vs. olpc2 variants? The way that I understand it based on Bernie's IRC explanation, is that these are different usage models based on how you interpret one of the keys. It is not a property of the keyboard per se, so I question whether this is something that should be in manufacturing data. As you say, it doesn't belong to manifacturing data. BUT... do we want keyboard autoconfiguration? If so, I don't know where else we could hardcode this bit of knowledge. Unless we admit shipping forked versions of hal and xkeyboard-config with a table for mapping manifacturing data to the actual XKB parameters. On Sat, 2007-10-06 at 15:25 -0400, Bernardo Innocenti wrote: Jim Gettys wrote: Bernie, please fill in the table below for the keyboard layout for each keyboard type we have ASAP, so we can get this to Quanta and I can get this all into the Wiki. Based on the olpc-configure script, plus our recent additions: Keyboard Layout KM KLKV olpc usolpc OLPC_Argentina_Keyboard olpc esolpc OLPC_Brasil_Keyboard olpc brolpc OLPC_Ethiopia_Keyboard olpc us,et olpc2,olpc OLPC_Libya_Keyboard OLPC_Nigeria_Keyboardolpc ngolpc OLPC_Rwanda_Keyboard olpc us,araolpc2,olpc OLPC_Thailand_Keyboard olpc us,th olpc2,olpc Urdu_Keyboardolpc us,ur olpc2,olpc Cyrillic_Keyboardolpc us,ru olpc2,olpc OLPC_Turkey_Keyboard olpc us,tr olpc2,olpc OLPC_Nepal_Keyboard olpc us,np olpc2,olpc (UNSURE) For Libya and Rwanda I have no idea. For Nepal, please double check. I also don't know who gets to use the arabic keymap. The KV flag is included for completeness: it should normally be a null string as Xkb has a notion of default variant. Yes, it does. But the default in xkeyboard-config is rarely ours. And it would be a pity if we couldn't use the pristine upstream package. I have xkb rules to deduce the variant from KM+KL, but olpc2 need to be specified manually. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
On Sat, 2007-10-06 at 16:33 -0400, Bernardo Innocenti wrote:
(adding devel@ to cc)
Mitch Bradley wrote:
Jim Gettys wrote:
What are the olpc vs. olpc2 variants?
The way that I understand it based on Bernie's IRC explanation, is that
these are different usage models based on how you interpret one of the keys.
It is not a property of the keyboard per se, so I question whether this
is something that should be in manufacturing data.
As you say, it doesn't belong to manifacturing data.
BUT... do we want keyboard autoconfiguration? If so, I don't know where
else we could hardcode this bit of knowledge.
Unless we admit shipping forked versions of hal and xkeyboard-config
with a table for mapping manifacturing data to the actual XKB parameters.
It is a property of how we want the keyboard to behave in a particular
manufacturing build.
Also, if olpc can be the default, we'd only be listing the olpc2 variant
when we need it...
In any case, I'll take this proposal to the devel list for more eyes...
- Jim
On Sat, 2007-10-06 at 15:25 -0400, Bernardo Innocenti wrote:
Jim Gettys wrote:
Bernie, please fill in the table below for the keyboard layout for each
keyboard type we have ASAP, so we can get this to Quanta and I can get
this all into the Wiki.
Based on the olpc-configure script, plus our recent additions:
Keyboard Layout KM KLKV
olpc usolpc
OLPC_Argentina_Keyboard olpc esolpc
OLPC_Brasil_Keyboard olpc brolpc
OLPC_Ethiopia_Keyboard olpc us,et olpc2,olpc
OLPC_Libya_Keyboard
OLPC_Nigeria_Keyboardolpc ngolpc
OLPC_Rwanda_Keyboard
olpc us,araolpc2,olpc
OLPC_Thailand_Keyboard olpc us,th olpc2,olpc
Urdu_Keyboardolpc us,ur olpc2,olpc
Cyrillic_Keyboardolpc us,ru olpc2,olpc
OLPC_Turkey_Keyboard olpc us,tr olpc2,olpc
OLPC_Nepal_Keyboard olpc us,np olpc2,olpc (UNSURE)
For Libya and Rwanda I have no idea. For Nepal, please double check.
I also don't know who gets to use the arabic keymap.
The KV flag is included for completeness: it should normally be a null
string as Xkb has a notion of default variant.
Yes, it does. But the default in xkeyboard-config is rarely ours.
And it would be a pity if we couldn't use the pristine upstream package.
I have xkb rules to deduce the variant from KM+KL, but olpc2 need
to be specified manually.
--
Jim Gettys
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
New manufacturing data flags for keyboards.
I've been chatting with Sergey Udaltsov about defining keyboard better, so we might introduce new keyboards without having to revise firmware or often even the software for new keyboard types we want to introduce. Right now, we have an unholy mess left from before B1, where we divine the keyboard type from the part numbers: this requires updating our distribution every time we need to introduce a new keyboard layout. There lies madness. Several typos fixed to make clear that a single keyboard can have multiple layouts, and the table heading was wrong. Here's a proposed set of additional manufacturing data tags, to get rid of the current kludge used for keyboard setup. See http://wiki.laptop.org/go/Manufacturing_Data for information on manufacturing data. Comments? Layouts Keyboard flags: OFW flag xkb meaning examples KM -model - olpc, pc105, KL -layouts -en_GB, es, fi, us,ar, us,ru KV -variant -olpc, olpc2, dvorak, winkeys, ,bksl, The KM flag should be set to olpc for all Gen-1 OLPC's with existing keyboards. The `` characters are *not* included int the manufacturing data. The KV flag is included for completeness; we use this as we define several layouts on the same keyboard. The KL flag describing the default layouts should be set to the following values, depending on keyboard: http://wiki.laptop.org/go/OLPC_Keyboard_layouts Keyboard Layout KL value KV value OLPC_Keyboard_layouts us olpc OLPC_Argentina_Keyboardes olpc OLPC_Brasil_Keyboard br olpc OLPC_Ethiopia_Keyboard us,etolpc2,olpc OLPC_Libya_Keyboardus,arolpc2,olpc OLPC_Nigeria_Keyboard ng olpc OLPC_Rwanda_Keyboard us olpc2,olpc OLPC_Thailand_Keyboard us,tholpc2,olpc Urdu_Keyboard us,urolpc2,olpc Cyrillic_Keyboard us,ruolpc2,olpc OLPC_Turkey_Keyboard us,trolpc2,olpc OLPC_Nepal_Keyboardus,npolpc2,olpc Once this is done, we can pass the keyboard information directly from the operating system to the X window system and have things just work to a great degree when we add additional keyboard layouts, presuming the values are set correctly in the factory to correspond to the ink that has been silk-screened on the keyboard. Comments? Questions? Mistakes? - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
Jim's proposal solves the X problem, and I think we should adopt it. We also have the problem of letting OFW and the Linux kernel know enough about the keyboard so developers can type US ASCII , which is the common subset that is sufficient for managing diagnostics, booting, and installation procedures. One solution would be to include a lot of keymaps in OFW and select one based on the new KL tag. However, I'm not keen on having to carry around a lot of keymaps in the ROM, and extend that list from time to time. I would rather have another new tag whose value is a map from US ASCII characters to the scancode+shift_state that corresponds to that character's printed location on the keyboard. The trivial encoding would be 9 bits per 7-bit US ASCII character - 7 bits for the scancode + 2 bits for one of four printing positions, hence 144 bytes, which fits easily in a mfg data tag. Note that I am explicitly and very intentionally limiting this to US ASCII. The extension to arbitrary international characters is a can of worms that would scuttle the entire scheme. This is just for booting/OFW/developer use. I will submit a more concrete proposal describing exact encodings later this weekend. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
Mitch Bradley wrote: One solution would be to include a lot of keymaps in OFW and select one based on the new KL tag. However, I'm not keen on having to carry around a lot of keymaps in the ROM, and extend that list from time to time. There's also a trivial, good enough solution to the problem: don't do anything. All non-US computer users like me have learned to live with it, and it's not as bad as it may seem to US users. In Italian, French and German layouts, there are typically just a few misplaced keys you need to care about... and those you don't remember are easy to find by trial and error. Really, if it's just for system recovery tasks, then it's just for techies. And if they're technical enough to type shell and forth commands, they're also going to understand the issue rather than complain my keys are messed up, I'm lost!. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
On Oct 7, 2007, at 0:08 , Bernardo Innocenti wrote: Mitch Bradley wrote: One solution would be to include a lot of keymaps in OFW and select one based on the new KL tag. However, I'm not keen on having to carry around a lot of keymaps in the ROM, and extend that list from time to time. There's also a trivial, good enough solution to the problem: don't do anything. All non-US computer users like me have learned to live with it, and it's not as bad as it may seem to US users. In Italian, French and German layouts, there are typically just a few misplaced keys you need to care about... and those you don't remember are easy to find by trial and error. Really, if it's just for system recovery tasks, then it's just for techies. And if they're technical enough to type shell and forth commands, they're also going to understand the issue rather than complain my keys are messed up, I'm lost!. I disagree. It's a major hassle if the keys you press do not do what's printed on them. Simply assuming a US layout when the machine can know quite well what keyboard is attached is unacceptable. It's a shortcoming of external keyboards that they do not communicate their physical layout to the host (*), but for the built-in keyboard in a laptop we should not have to live with this. Yes, I learned to find the most important keys even on a German keyboard that the software assumed to be English. Still, I hate it every single time it happens. Jim's proposal means this *could* be solved for good. Yay! - Bert - (*) the OS should let you choose the layout for every keyboard newly attached, and then remember that setting. For some reason that I don't understand, no OS allows to use a German and English keyboard in parallel. They all can only have one keymap active at a time. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
Bert Freudenberg wrote: I disagree. It's a major hassle if the keys you press do not do what's printed on them. Simply assuming a US layout when the machine can know quite well what keyboard is attached is unacceptable. It's a shortcoming of external keyboards that they do not communicate their physical layout to the host (*), but for the built-in keyboard in a laptop we should not have to live with this. We're talking about the recovery consoles and firmware prompt... In our case, it's clearly not a matter of detecting the correct keyboard, but rather including a potentially large amount of different keymaps in low-level components of the system such as OFW and kernel. These components shouldn't need updating every time a new keyboard come out. (*) the OS should let you choose the layout for every keyboard newly attached, and then remember that setting. For some reason that I don't understand, no OS allows to use a German and English keyboard in parallel. They all can only have one keymap active at a time. An unfortunate leftover from when there was a 1-1 relation between keyboards and terminals or consoles. I think X could now do the right thing now with evdev: each driver instance gets its xkb settings in xorg.conf. Oddly, there's no way to specify the device from setxkbmap, so we'll once again loose this feature when xorg.conf gets phased out. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
Back to the original question, in case it is needed: Keyboard Layout KM KLKVComment USInternational_Keyboard olpc usolpc OLPC_Argentina_Keyboard olpc esolpc (Spanish) OLPC_Brasil_Keyboard olpc brolpc (Portuguese) OLPC_Ethiopia_Keyboard olpc us,et olpc2,olpc OLPC_Libya_Keyboard olpc us,araolpc2,olpc(Arabic) OLPC_Nigeria_Keyboardolpc ngolpc (for West Africa) OLPC_Rwanda_Keyboard (eliminated) OLPC_Thailand_Keyboard olpc us,th olpc2,olpc Urdu_Keyboardolpc us,ur olpc2,olpc Cyrillic_Keyboardolpc 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 -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
Bernardo Innocenti wrote: Mitch Bradley wrote: One solution would be to include a lot of keymaps in OFW and select one based on the new KL tag. However, I'm not keen on having to carry around a lot of keymaps in the ROM, and extend that list from time to time. There's also a trivial, good enough solution to the problem: don't do anything. All non-US computer users like me have learned to live with it, and it's not as bad as it may seem to US users. In Italian, French and German layouts, there are typically just a few misplaced keys you need to care about... and those you don't remember are easy to find by trial and error. Really, if it's just for system recovery tasks, then it's just for techies. And if they're technical enough to type shell and forth commands, they're also going to understand the issue rather than complain my keys are messed up, I'm lost!. I have two complaints in the last two days from techies. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
Re: New manufacturing data flags for keyboards (2nd draft). Keyboard Layout KMKL 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_Keyboardolpc ng olpc(for West Africa) OLPC_Thailand_Keyboard olpc us,th olpc2,olpc Urdu_Keyboardolpc us,ur olpc2,olpc Cyrillic_Keyboardolpc 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. Supplying mapping data would be nice as well. 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. 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. 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
