Opened 4 years ago

Closed 4 years ago

#12645 closed defect (fixed)

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
Blocked By: Blocking:
Deployments affected: Action Needed: package
Verified: no


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}
  • * +
  • > <
  • [ { Ç
  • ] }

Attachments (2)

es (9.8 KB) - added by walter 4 years ago.
olpcm.patch (2.2 KB) - added by walter 4 years ago.

Download all attachments as: .zip

Change History (28)

comment:1 Changed 4 years ago by greenfeld

  • Component changed from ofw - open firmware to distro
  • Owner changed from wmb@… to wad

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.

comment:2 Changed 4 years ago by greenfeld

KA tag rather (instead of LA)

comment:3 Changed 4 years ago by wad

  • Cc pgf added
  • Keywords XO-4 spanish keyboard added
  • Milestone changed from 13.1.0 to 13.2.0
  • Status changed from new to assigned

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 ) for Linux, but it may not have been properly upstreamed.

comment:4 Changed 4 years 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. ;-)

comment:5 Changed 4 years ago by wad

  • Action Needed 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 ?

comment:6 Changed 4 years 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).

comment:7 Changed 4 years 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).

comment:8 Changed 4 years ago by pgf

i've created the KA tag for spanish HS here:

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.

comment:9 Changed 4 years ago by pgf

to set the KA tag, go to 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:

Changed 4 years ago by walter

comment:10 Changed 4 years 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 4 years ago by walter

comment:11 Changed 4 years 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.

comment:12 Changed 4 years 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]).


comment:13 Changed 4 years ago by wad

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

comment:14 Changed 4 years ago by dsd

  • Action Needed changed from design to package
  • Cc dsd added

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.

comment:15 Changed 4 years 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....

comment:16 Changed 4 years 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.

comment:17 Changed 4 years ago by dsd

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

comment:18 Changed 4 years 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; 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).

comment:19 Changed 4 years 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.

comment:20 Changed 4 years ago by dsd

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

comment:21 Changed 4 years 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.

comment:22 Changed 4 years ago by wad

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

comment:23 Changed 4 years 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.

comment:24 Changed 4 years 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

comment:25 Changed 4 years ago by dsd

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

comment:26 Changed 4 years ago by dsd

  • Resolution set to fixed
  • Status changed from assigned to closed

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.