Ticket #12645 (closed defect: fixed)

Opened 18 months ago

Last modified 16 months ago

Spanish HS Keyboard OFW/Linux definitions likely incorrect

Reported by: greenfeld Owned by: wad
Priority: high Milestone: 13.2.0
Component: distro Version: Development build as of this date
Keywords: XO-4 spanish keyboard Cc: pgf, dsd
Action Needed: package Verified: no
Deployments affected: Blocked By:


SKU: 301 (Spanish HS keyboard), build 31036o4

The Spanish HS Keyboard OFW & Linux definitions seem to be missing proper definitions for at least the following keys:

  • ¡ ¿ \ {Makes it hard to fs-update without an external keyboard}
  • * +
  • > <
  • [ { Ç
  • ] }


es (9.8 kB) - added by walter 17 months ago.
olpcm.patch (2.2 kB) - added by walter 17 months ago.

Change History

Changed 18 months ago by greenfeld

  • owner changed from wmb@… to wad
  • component changed from ofw - open firmware to distro

This isn't necessarily OFW's fault.

This could be a combination of the wrong LA tag being added by the factory as well as an incorrect Linux keyboard definition even though KM is olpcm and KL is es.

Changed 18 months ago by greenfeld

KA tag rather (instead of LA)

Changed 18 months ago by wad

  • cc pgf added
  • keywords XO-4 spanish keyboard added
  • status changed from new to assigned
  • milestone changed from 13.1.0 to 13.2.0

This is due to the KA tag used being the wrong one. I just checked, and this was probably the one used on all the Uruguay Spanish HS keyboards (the SKU 121 unit I have doesn't properly support the spanish mechanical keyboard from OFW).

A work-around for OFW is that the \ is present at AltGr-7 (where it is on the non-mechanical Spanish keyboard).

I'm looking into generating the right one, it shouldn't be too hard. Paul Fox definitely checked in a Spanish olpcm keyboard (see http://dev.laptop.org/git/projects/keyboard-data/tree/F-11/symbols/es ) for Linux, but it may not have been properly upstreamed.

Changed 18 months ago by pgf

i'd guess the answer lies somewhere here:


or here:


the upstreaming process wasn't exactly seamless, apparently.

and given how seamless it wasn't, i'll now take issue with your "it shouldn't be too hard" comment. ;-)

Changed 18 months ago by wad

  • next_action changed from diagnose to design

A bisection shows that the regression occurred between 11.3 and 12.1. Build 11.3.1 (os885) works fine (released June 2012, first in July 2011), and build 12.1.0-build21 fails (released Aug. 2012).

Looking in /usr/share/X11/xkb/, there were a number of pieces which didn't get picked up upstream. The olpcm part of the es symbols file, any rules for olpcm variants, and the olpc compat file (enabling game keys as keyboard keys).

The olpcm implementation as originally proposed seems un-necessary, as there are no keys in the union of the two keycode sets which have multiple symbols bound to them. So I tried merging it into the es(olpc) definition instead. The problem is that some keys in the es(olpc) definition aren't defined using actual keycodes, but instead use symbolic keycodes (TLDE, BKSL, I219). I'll try finding actual keycodes for these later today.

I don't know about the missing compat file. Was this dropped intentionally ? It does allow scrolling around many apps using the game keys on non-touch machines.

The rule changes should be unnecessary if we merge the symbols descriptions ?

Changed 18 months ago by wad

OK, we've dug through and the root of the problem is that both the EC (and the later SP code) reused the same scan code for different keys in the keyboard. This makes it impossible to use a single mapping at the higher level (merged symbol descriptions).

Unless we are willing to change the EC and Linux code on all laptops after 1.5 HS, we are better off reverting to the older xkb symbol file for es (along with the rules files).

Changed 18 months ago by pgf

i've replaced the existing xkeyboard-config-2.6 rpm with


which is what was included in build 885, and the spanish mechanical keyboard now works correctly. i didn't check any others.

i'm very surprised that this bug wasn't reported in the 12.1.0 timeframe. what does UY put in their releases?

in any case, i think that unless we think the upstream package contains some mapping that we vitally need, we should revert to the 1.9-11 vintage, which seems to work. and then we should pursue getting the Right Thing to happen upstream (again).

Changed 18 months ago by pgf

i've created the KA tag for spanish HS here: http://dev.laptop.org/git/projects/ofw-ka-files/tree/esmech.ka

i started trying to use the tool, to extract the KA tag from the X keyboard config, but it seemed easier to modify the ES membrane KA tag, since so few characters were affected.

in addition to the characters listed in the ticket description, the ascii '~' (tilde) key is also fixed.

Changed 17 months ago by pgf

to set the KA tag, go to http://dev.laptop.org/git/projects/ofw-ka-files/tree/ and put at least the files setka.fth and esmech.ka on a USB stick. on the target XO, run

ok fload setka.fth esmech

this process is documented here: http://wiki.laptop.org/go/Creating_A_New_Keyboard_Layout#Testing_the_.ka_file

Changed 17 months ago by walter

  • attachment es added

Changed 17 months ago by walter

I've attached a new es symbol file with an olpc3 variant to work with this layout in X windows. Will look into upstreaming. I don't recall where OLPC sets the keyboard variant; I have been testing just using:

setxkbmap -layout es -variant olpc3

Changed 17 months ago by walter

Changed 17 months ago by walter

As part of the upstream staging, I've attached a patch (olpcm.patch) to add the olpcm section to the current version of the es symbol file. (The file patched in pgf's comment is not current.) Also, FWIW, I cleaned up the formatting a bit to make it easier to read.

Changed 17 months ago by walter

Just to keep everyone up to date, I screwed up by submitting a patch based on Martin's repository instead of grabbing a fresh copy of master. I've subsequently regenerated and resubmitted the patch (Follow the action at [1]).

[1] https://bugs.freedesktop.org/show_bug.cgi?id=34738

Changed 17 months ago by wad

The corrected KA tag has been submitted to Quanta for use in future manufacturing.

Changed 17 months ago by dsd

  • cc dsd added
  • next_action changed from design to package

Many thanks to Walter for getting that patch upstream.

I will add it to Fedora (and our builds), but I'd like someone to test the package first, on an XO-4 laptop that has this keyboard (with correct mfg data). Any volunteers?


Install the package, then "rm /.olpc-configured" and reboot.

Changed 17 months ago by wad

Almost there, but not quite right.

Testing with that package shows that the "upside down question mark" key still isn't being mapped properly. Many other keys are properly mapped by that package (such as tilde being AltGr 4) It is mapped differently than before the package is installed, but not right.

The new (wrong) mapping is left apostrophe for unshifted, tilde for shifted, and nothing for AltGr.

The correct mapping should be "upside down question mark", "upside down exclamation" for shifted, and backslash for AltGr.

That was testing using "Write".

When testing the new package using a VT and the shell, backslash DOES appear at AltGr upside down question mark, but tilde isn't at AltGr 4 anymore....

Changed 17 months ago by greenfeld

This has been seen before with Write (#10250).

I vaguely remember this being Write-specific, so try with another activity, or in Sugar itself by typing into one of the Search/Journal name/etc. fields.

Changed 17 months ago by dsd

Thanks for testing. Can you let me know the relevant mfg tags of these laptops so that I can try here?

Changed 17 months ago by wad

Samuel, Nice catch, but no go. Testing with the Sugar Journal search field shows exactly the same problem.

This isn't my first time playing with this bug. I had already used Write to test that the old rpm fixed the problem (and just retested as my memory isn't as good as it used to be).

The manufaturing data is SKU 301; KL es; KM olpcm; KV olpc; KA same as http://dev.laptop.org/git/projects/ofw-ka-files/tree/esmech.ka; LO es_UY.UTF-8.

The troublesome key is the one right under the ESC key (XKB raw key code AE00, usually aliased as TLDE).

Changed 17 months ago by walter

from the es symbol file for olpcm

key <AE00> { [ questiondown, exclamdown, backslash ] }; key <AE04> { [ 4, dollar, asciitilde, dead_tilde ] };

So either the AE00 alias is not working or the correct layout is not being selected. I suspect the latter since wad reports that asciitilde is not mapped to the 4 key either.

Changed 17 months ago by dsd

wad, can you post the contents of /etc/sysconfig/keyboard on this XO?

Changed 17 months ago by wad

I'm sorry, that key is the screwed up one. That is the key for which Richard decided to return the same key code (TLDE ?) even though the keys on the two keyboards are mapped as separate keys in the key matrix.

It is the reason we can't just assign AE00 to those keys, and leave TLDE assigned to the ones used on the english keyboard.

I think if above key symbol assignment line is changed to key <TLDE> {[...]}; this will work.

Changed 17 months ago by wad

/etc/sysconfig/keyboard has the expected values: XKBMODEL="olpcm" XKBLAYOUT="es" XKBVARIANT="olpc"

Changed 17 months ago by wad


With the new (broken) package, tilde is available as AltGr-4 in Sugar and Write.

Tilde not being mapped to AltGr-4 in VT mode is a huge problem, but it is limited to VT mode. It is also a problem with the old OLPC rpm for xkeyboard indicated by Paul above (which fixes everything in Sugar). This is probably a separate bug.

Changed 17 months ago by dsd

We have a fix for the ¿¡ key on the upstream bug but it has gone quiet, so I'll just package it locally for now, ready for the next build. If anyone wants to try it beforehand, the RPM is http://rpmdropbox.laptop.org/f18/xkeyboard-config-2.6-7.fc18.olpc1.noarch.rpm

Changed 16 months ago by dsd

This is included in 13.2.0 build 6. I'll leave this ticket open until we have it fixed upstream.

Changed 16 months ago by dsd

  • status changed from assigned to closed
  • resolution set to fixed

Tested in 13.2.0 build 6, the problem keys are working, including the AE00 key. The final patch went upstream and I added this to Fedora as xkeyboard-config-2.6-8.fc18

Note: See TracTickets for help on using tickets.