Opened 7 years ago

Last modified 5 years ago

#6973 new defect

Production problem: Haiti keyboard doesn't match keyboard mappings

Reported by: kimquirk Owned by: arjs
Priority: blocker Milestone: 8.1.1 (was Update1.1)
Component: keyboards Version:
Keywords: Cc: dgilmore, mstone, kimquirk, sayamindu, cjl
Blocked By: Blocking:
Deployments affected: Action Needed: never set
Verified: no

Description

Build 703, q2d14

If you open the terminal activity on a laptop with Haiti mfg settings (http://wiki.laptop.org/go/Mfg-data); and type characters you will get incorrect mappings.

For instance, QWERTY, comes out AWERTY.

Email notes from Arjun:
There seems to be a bug in the xkb symbol file (ca) for laptops for Haiti.

Details of the bug -->
In the olpc section of the xkb symbol file found in
/usr/share/X11/xkb/symbols/ca the default group has been wrongly
included.

The line reads

include "fr"

it should actually be

include "ca(fr)"

Hence X was loading the French layout which is not a QWERTY layout.

One can test by making modifications in /usr/share/X11/xkb/symbols/ca
and rebooting.
Only this one line, that appears towards the end of the xkb symbol
file needs to be changed.

Attachments (1)

6973.patch (871 bytes) - added by sayamindu 7 years ago.
Updated patch. This should fix all pending issues.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 7 years ago by kimquirk

  • Owner changed from walter to kimquirk
  • Priority changed from high to blocker

comment:2 Changed 7 years ago by kimquirk

  • Owner changed from kimquirk to arjs

comment:3 Changed 7 years ago by arjs

  • Cc dgilmore mstone kimquirk added

I can submit a patch for this , but someoene with build access in Fedora would need to build the rpm. Last time dgilmore did it. Michael/Dennis will any of you be able to build xkeyboard-config for me in Fedora ?

comment:4 Changed 7 years ago by sayamindu

I can confirm that Arjun's fix works here.

comment:5 Changed 7 years ago by sayamindu

  • Cc sayamindu added

comment:6 Changed 7 years ago by sayamindu

New version of xkeyboard-config built: http://koji.fedoraproject.org/koji/taskinfo?taskID=611221

comment:7 Changed 7 years ago by mstone

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

comment:8 Changed 7 years ago by sayamindu

Confirmed that this has been fixed in 704.

comment:9 follow-up: Changed 7 years ago by arjs

Sorry I will be able to get some time in a few days, but just quickly - Sayamindu from where did you pull the source for building the rpm.
I am saying this because the xkeyboard-config rpm that we ship as part of Update.1 is greatly divergent from fredesktop upstream. It was planned to sync after update.1
Would it be possible to take the previous rpm that dgilmore had built for all update1 and apply this patch to that ? (please ignore this if this is what has been done)

comment:10 in reply to: ↑ 9 Changed 7 years ago by sayamindu

Replying to arjs:

Sorry I will be able to get some time in a few days, but just quickly - Sayamindu from where did you pull the source for building the rpm.
I am saying this because the xkeyboard-config rpm that we ship as part of Update.1 is greatly divergent from fredesktop upstream. It was planned to sync after update.1
Would it be possible to take the previous rpm that dgilmore had built for all update1 and apply this patch to that ? (please ignore this if this is what has been done)

I used the Koji to build the RPM, with the patches from http://cvs.fedoraproject.org/viewcvs/rpms/xkeyboard-config/OLPC-2/. Are there any more patches that must be added ?

comment:11 follow-up: Changed 7 years ago by kimquirk

Test of build 704 showed that we now have a qwerty instead of awerty keyboard, but there are still many incorrect key mappings (ref: http://wiki.laptop.org/go/OLPC_French_%28ca%29%28ht%29_Keyboard):

  • Top character row: looks like we manufactured the silkscreen incorrectly and put the underscore as the non-shift character and the minus for the shift. I recommend that we leave this keymap incorrect because people will figure it out and the usual for all keyboards (even for French Canadian by wikipedia) is for minus to be the non-shifted character.
  • altgr for top character row: only two characters in this row have an altgr, the first key and the "2" key, which is incorrectly an at sign. Every key should have an altgr character.
  • Second character row: none of the altgr work on this row. Also, it takes two keystrokes to get the , to the right of the P. No other characters (shift or altgr) show up. No characters ever display for the key just to the left of enter (shift, no shift, or altgr).
  • Third character row: The single quote character has to be pushed twice to get it to display.
  • Fourth character row: No character displays when you hit the key just to the left of the shift or the key to the right of the page up. The mu doesn't work with altgr on the M key; the underscore and hyphen don't work (also altgr keys)

comment:12 in reply to: ↑ 11 Changed 7 years ago by sayamindu

Replying to kimquirk:

Test of build 704 showed that we now have a qwerty instead of awerty keyboard, but there are still many incorrect key mappings (ref: http://wiki.laptop.org/go/OLPC_French_%28ca%29%28ht%29_Keyboard):

  • Top character row: looks like we manufactured the silkscreen incorrectly and put the underscore as the non-shift character and the minus for the shift. I recommend that we leave this keymap incorrect because people will figure it out and the usual for all keyboards (even for French Canadian by wikipedia) is for minus to be the non-shifted character.
  • altgr for top character row: only two characters in this row have an altgr, the first key and the "2" key, which is incorrectly an at sign. Every key should have an altgr character.

Looks like someone swapped the alt-gr mapping for 2 and 3 - fixing that.
However, for the rest of the keys, alt-gr works correctly for me.

  • Second character row: none of the altgr work on this row. Also, it takes two keystrokes to get the , to the right of the P. No other characters (shift or altgr) show up. No characters ever display for the key just to the left of enter (shift, no shift, or altgr).

Can confirm that the Euro sign does not come. Isolated the problem, and fixing it. However, I do get the alt-gr characters for O and P. For the key to the right of p, the definition is

key <AD11>	{ [dead_circumflex, dead_circumflex, bracketleft  ]	};

I'm not very sure how dead_circumflex is supposed to be used. It is a dead key, so press that key, followed by, say e to get a ê. I think that is the intended behaviour.
Same for the key to left of Enter. However I get a ']' by pressing alt-gr and that key.

  • Third character row: The single quote character has to be pushed twice to get it to display.

Dead key. Press that key followed by e.

  • Fourth character row: No character displays when you hit the key just to the left of the shift or the key to the right of the page up. The mu doesn't work with altgr on the M key; the underscore and hyphen don't work (also altgr keys)

Dead key. Press that key followed by e. Mu works for me. Hyphen does not come, and the other thing is not an underscore - it is a Macron (http://en.wikipedia.org/wiki/Macron).

Changed 7 years ago by sayamindu

Updated patch. This should fix all pending issues.

comment:13 Changed 7 years ago by sayamindu

Patch committed to Koji and new package built. http://koji.fedoraproject.org/koji/buildinfo?buildID=50582

comment:14 follow-up: Changed 7 years ago by mstone

The following keys are improperly mapped on SKU 24 in 706:

B8  - (containing M and mu)   - No alt-gr map
B11 - (containing E' and ')   - No mappings
B14 - (containing << and >>)  - No mappings
C12 - (containing ` and {)    - two presses needed
D4  - (containing e and euro) - no alt-gr map
D10 - (containing o)          - no alt-gr map
D11 - (containing p)          - no alt-gr map
D12 - (containing ^ and [)    - two presses required for ^
D13 - (containing ])          - normal and shift unmapped
E3,5,6,7,8,9,10,11,12,13      - alt-gr not mapped
 2,4,5,6,7,8,9 , 0, -, +        (contained digits)

comment:15 Changed 7 years ago by mstone

Actually, it turns out that VTE, the terminal widget used in Terminal is at fault. Typing these keys in the mesh search bar shows that they are correctly mapped.

comment:16 in reply to: ↑ 14 Changed 7 years ago by arjs

With respect to 708, which contains
xkeyboard-config.noarch 0:1.1-20.20071130cvs.olpc2

I tested all of the following in the Terminal Activity.

Replying to mstone:

The following keys are improperly mapped on SKU 24 in 706:

B8  - (containing M and mu)   - No alt-gr map

(you are referring to B7) seems fixed in 708

B11 - (containing E' and ') - No mappings

B11 is the shift key?

B14 - (containing << and >>) - No mappings

mapped as <I219>, (also sometimes known as the language switch key), working fine in 708

C12 - (containing ` and {) - two presses needed

tested to be working fine in 708

D4 - (containing e and euro) - no alt-gr map

(you are referring to D3) working ok in 708

D10 - (containing o) - no alt-gr map

(thats D9) tested to be working fine in 708

D11 - (containing p) - no alt-gr map

(thats D10) tested to be working fine in 708

D12 - (containing and [) - two presses required for

(thats D11) tested to be working fine in 708

D13 - (containing ]) - normal and shift unmapped

(thats D12) tested to be working fine in 708. Note that two characters (the ones except for ]) will appear only when pressed twice. This is characteristic of how dead characters are generated.

E3,5,6,7,8,9,10,11,12,13 - alt-gr not mapped

resolved in 708.

2,4,5,6,7,8,9 , 0, -, + (contained digits)

resolved in 708

}}}

Also 6973.patch is fine as is evident by all key mapping problems having being resolved in 708.

All in all, this ticket seems ready to be closed .

comment:17 Changed 7 years ago by sayamindu

Just a minor nitpick.... Try to avoid the terminal activity for keyboard testing. The terminal widget is not very good when it comes to handling character input.

comment:18 Changed 6 years ago by sayamindu

  • Action Needed set to never set

comment:19 Changed 5 years ago by cjl

  • Cc cjl added

The upstream bug shows as fixed. Does this need to be kept open?

Note: See TracTickets for help on using tickets.