MFG Problem: Ethiopian keyboards don't provide English characters

[kimquirk]

Build 703, q2d14 (must be a fresh install AFTER setting the mfg-data for ethiopian keyboard)

This is holding up production of Ethiopian laptops at Quanta.

I set the mfg-data to mimic an Ethiopian keyboard using info from here: http://wiki.laptop.org/go/Mfg-data

• KL = us,et
• KV = olpc2,basic
• LO = am_ET.UTF-8
• KA ref = us

After the cleaninstall of a 703, when you get the name screen, I type characters and they come out in Ahmaric. I press the change character set button (lower right below Enter key); and the characters are still Ahmaric (they should be English).

In Pippy, Terminal activity, and Abiword - I can't get English.

In linux virtual terminal, all characters are English (this is ok).

When I went into the linux virtual terminal after the boot up, there are a bunch of errors including the final one:

More than one layout variant on command line Using "et", ignoring "olpc2,basic".

[kimquirk]

var/log/messages

[cjb]

Adding Mitch to CC in case he has ideas.

[kimquirk]

/etc/sysconfig/keyboard is:

KEYTABLE="us" XKB_MODEL="olpc" XKB_LAYOUT="us,et" XKB_VARIANT="olpc2,basic"

[arjs]

If the locale is set to en_US.UTF-8 one can see English characters, but I confirm that with locale settings at am_ET.UTF-8 , which is infact correct for Ethiopian Keyboard laptops (Bernie, please confirm) one can't seem to be able to type English characters even after pressing the language switch key.

These tags, according to me are fine.

KL = us,et KV = olpc2,basic LO = am_ET.UTF-8 KA ref = us

And, they seem to be doing the right things for sugar too. For the keyboard layout part, Kim's /etc/sysconfig/keyboard after first boot is getting set to

KEYTABLE="us"

XKB_MODEL="olpc"

XKB_LAYOUT="us,et"

XKB_VARIANT="olpc2,basic"

which seems fine.

Additionally, please verify the contents of /home/olpc/.i18n after first boot, they should be LANG=am_ET.UTF-8

It seems like a software bug, not production/keyboards related.

[arjs]

Bernie, can you please update this ticket with multiple issues that you mentioned once, that are causing this problem ?

[sayamindu]

I think I found the culprit (the small underlines on the text, as it was being written, provided the clue). It looks like we still ship the GTK input modules, one of which is Ethiopian ("Tigrigna-Ethiopian (EZ+)"). Since the locale is set to em_ET, that GTK-IM is getting activated, superseding the XKB stuff that we currently rely on. Possible solutions to this is either to avoid shipping the GTK-IMs altogether (do we really need them ?), or to modify GTK+ (or .gtkrc somehow) to avoid the GTK IM from getting selected by default. I would vote for removing the GTK IM modules if we do not require them, as it would save space, and kids will not accidentally choose them.

[sayamindu]

Sorry, apparently it is the Amharic EZ+ module which is getting activated. The following line in /etc/gtk-2.0/i386-redhat-linux-gnu/gtk.immodules seems to be causing it:

"/usr/lib/gtk-2.0/2.10.0/immodules/im-am-et.so" 
"am_et" "Amharic (EZ+)" "gtk20" "/usr/share/locale" "am" 

[sayamindu]

Patch against olpc-session (in olpc-utils) which explicitly sets the gtk-input module to "Default"

[sayamindu]

New version of olpc-utils built http://koji.fedoraproject.org/koji/taskinfo?taskID=611349

[mstone]

update.1-704 contains this change and is available for testing.

[sayamindu]

I can confirm that 704 fixes this problem. I set my mfg-tags to mimic a Ethiopian machine, did a copy-nand, and it seems to work fine.

[kimquirk]

I did a copy-nand of build 704 on my amharic SKU 11 laptop (the real thing from Quanta), and I can get English characters... but the change language key doesn't give me the ability to get amharic characters!

I tried from the opening 'NAME: ' screen as well as in the terminal activity. No Amharic.

What happened? (Did you actually see Amharic, Sayamindu?)

[kimquirk]

I noticed that mfg-data for KL is "us, et" (note that there is a space after the comma). Could this cause the problem?

[kimquirk]

I just answered my own question. Ouch! I fixed the mfg-data so that KL="us,et", with no space, then I re-imaged 704 and now I get both English AND Amharic.

Is is a reasonable request to ask that the code we control (olpc-utils, or whatever) allow for a space or no space? Unfortunately, we can't ask Ethiopia to change their mfg-data.

[sayamindu]

Replying to kimquirk:

I just answered my own question. Ouch! I fixed the mfg-data so that KL="us,et", with no space, then I re-imaged 704 and now I get both English AND Amharic. Is is a reasonable request to ask that the code we control (olpc-utils, or whatever) allow for a space or no space? Unfortunately, we can't ask Ethiopia to change their mfg-data.

a tr -d '[:space:]' should do the trick (it will remove all spaces). However, I'm not sure if it's safe to include this now, since it might mess up some configurations which require the use of space. Does such a configuration exist ? Mstone - any comments on this ?

[sayamindu]

Patch which strips spaces out of the KL tag in mfg-data.

[sayamindu]

Koji build with patch applied at http://koji.fedoraproject.org/koji/taskinfo?taskID=630186

[mstone]

Now that US/Amharic keyboards are correctly detected by olpc-configure, we've got to get the right keymap in place.

The current us,et keymap has a couple of problems:

C12 (containing ' and ") has no et mappings; it only has us mappings. C13 (containing \ and |) did not have a correct altgr_shift mapping. B4 (containing c) is not mapped in et B11 (containing / and ?) is correctly not mapped in et E1 (containing ` and ~) requires two key presses in et and one in us. D9 (containing i) + alt_gr, in the us layout, produces a character which breaks backspacing in the terminal. This might be a terminal bug.

[mstone]

Second attempt, with better formatting.

C12 (containing ' and ") has no et mappings; it only has us mappings. 
C13 (containing \ and |) did not have a correct altgr_shift mapping. 
B4 (containing c) is not mapped in et 
B11 (containing / and ?) is correctly not mapped in et 
E1 (containing ` and ~) requires two key presses in et and one in us. 
D9 (containing i) + alt_gr, in the us layout, produces a character 
    which breaks backspacing in the terminal. Maybe a terminal bug?

[mstone]

D9 appears to trigger bugs in VTE. The other keys are improperly mapped according to the mesh text buffer.

[sayamindu]

E1 is probably mapped to a dead accent. I'm not sure whether that is intended or not. C13 (containing \|) is confusing me. Is that a hyphen ?

[sayamindu]

Patch against the et symbol file to take care of the remaining issues (that thing is a hyphen)

[sayamindu]

Build request submitted to Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=636876

[kimquirk]

This has been fixed and tested in builds 706 and greater.