Ticket #6945 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

MFG Problem: Ethiopian keyboards don't provide English characters

Reported by: kimquirk Owned by: sayamindu
Priority: blocker Milestone: 8.1.1 (was Update1.1)
Component: keyboards Version:
Keywords: Cc: bernie, jg, arjs, wmb@…, mstone, sayamindu
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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".

Attachments

messages (59.9 kB) - added by kimquirk 6 years ago.
var/log/messages
6945.patch (0.6 kB) - added by sayamindu 6 years ago.
Patch against olpc-session (in olpc-utils) which explicitly sets the gtk-input module to "Default"
6945v2.patch (0.6 kB) - added by sayamindu 6 years ago.
Patch which strips spaces out of the KL tag in mfg-data.
xkeyboard-config-olpc-et.patch (1.5 kB) - added by sayamindu 6 years ago.
Patch against the et symbol file to take care of the remaining issues (that thing is a hyphen)

Change History

Changed 6 years ago by kimquirk

var/log/messages

  Changed 6 years ago by cjb

  • cc wmb@… added

Adding Mitch to CC in case he has ideas.

  Changed 6 years ago by kimquirk

/etc/sysconfig/keyboard is:

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

  Changed 6 years ago by kimquirk

  • owner changed from walter to wmb@…

  Changed 6 years ago by arjs

  • cc arjs added; arjun removed

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.

  Changed 6 years ago by mstone

  • cc mstone added

  Changed 6 years ago by kimquirk

  • owner changed from wmb@… to arjs

  Changed 6 years ago by arjs

  • owner changed from arjs to bernie

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

  Changed 6 years ago by 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.

  Changed 6 years ago by sayamindu

  • cc sayamindu added

  Changed 6 years ago by 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" 

Changed 6 years ago by sayamindu

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

  Changed 6 years ago by sayamindu

  Changed 6 years ago by mstone

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

  Changed 6 years ago by 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.

  Changed 6 years ago by kimquirk

  • owner changed from bernie to sayamindu

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?)

  Changed 6 years ago by 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?

follow-up: ↓ 17   Changed 6 years ago by 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.

in reply to: ↑ 16   Changed 6 years ago by 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 ?

Changed 6 years ago by sayamindu

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

  Changed 6 years ago by sayamindu

  Changed 6 years ago by 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.

  Changed 6 years ago by 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?

  Changed 6 years ago by mstone

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

  Changed 6 years ago by 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 ?

Changed 6 years ago by sayamindu

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

  Changed 6 years ago by sayamindu

  Changed 6 years ago by kimquirk

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

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

Note: See TracTickets for help on using tickets.