Can't use fr/oss keyboard layout by default

[Michael Terry]

[Impact]
The fr(oss) keyboard layout (and a couple others) fail to load, leaving the user with a US layout.

[Development Fix]
In the upstream bug tracker is a patch from Peter Hutterer which identifies a flaw in the ossmath map (which is included in keypad(oss), which is in turn pulled in by fr(oss)). This patch has been included in Quantal.

[Stable Fix]
Same patch as in quantal is proposed here.

[Test Case]
1. Add the French (alternative) layout as first listed before US.
2. Reboot
3. After rebooting, the indicator menu shows French (alternative) selected.
4. On a US keyboard, tap the 'm' key

Broken Behavior: 'm' is printed, as per the US keymap
Fixed Behavior: ',' is printed, as per the fr(oss) keymap

[Regression Potential]
The patch has not been committed to the upstream git tree; I usually like to see it taken upstream before we take it in ubuntu, but the patch itself seems to be good. Still, I'm hoping we'll see upstream commit the patch before we roll this out to -updates.

ossmath is included in a number of keymaps (although far from all), so the impact of a regression would be larger than just users of fr(oss).

[Original Report]
This is a break-out bug from bug 960096. Also ref https://bugs.freedesktop.org/show_bug.cgi?id=47671

When you have fr/oss "French (alternative)" layout as your first layout, you end up with "us" instead.

If you enable libxklavier debugging output, you'll see the following in your logs:

"Unexpected by libxklavier X ERROR: 0x8351fb8, 163f0005, 2 [], X11 request: 145, minor code: 9"

                xkl_debug(200,
                          "Unexpected by libxklavier X ERROR: %p, "
                          WINID_FORMAT ", %d [%s], "
                          "X11 request: %d, minor code: %d\n", dpy,
                          (unsigned long) evt->resourceid,
                          (int) evt->error_code, buf,
                          (int) evt->request_code, (int) evt->minor_code);

That 2 in there is the X error code, which means _XkbErrMissingTypes for xkbfile extension. I assume 145 is the major op code that got assigned for the XKBFile extension. If so, 9 is the X_kbSetMap request. Which all fits with an error trying to set the new layout map.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: xorg 1:7.6+12ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-23.36-generic-pae 3.2.14
Uname: Linux 3.2.0-23-generic-pae i686
.tmp.unity.support.test.0:

ApportVersion: 2.0.1-0ubuntu4
Architecture: i386
CheckboxSubmission: 9a284f3f6b4f7829abbe27ad9573a709
CheckboxSystem: 3935143777c965daaa64b51f0134f712
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
CompositorRunning: compiz
Date: Wed Apr 18 12:31:05 2012
DistUpgraded: 2011-11-05 19:49:52,977 DEBUG enabling apt cron job
DistroCodename: precise
DistroVariant: ubuntu
DkmsStatus: virtualbox, 4.1.12, 3.2.0-23-generic-pae, i686: installed
EcryptfsInUse: Yes
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
 Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 18) (prog-if 00 [VGA controller])
   Subsystem: CLEVO/KAPOK Computer Device [1558:3100]
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release i386 (20110422)
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
 Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
MachineType: System76, Inc. Lemur UltraThin
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic-pae root=UUID=0e585e80-16f1-404c-80cc-7d9805fcc3b0 ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: Upgraded to precise on 2011-11-05 (164 days ago)
dmi.bios.date: 11/11/2010
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: CALPELLACRB.86C.0000.X.0000000000
dmi.board.asset.tag: Tag 12345
dmi.board.name: Lemur UltraThin
dmi.board.vendor: System76, Inc.
dmi.board.version: lemu2
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: System76, Inc.
dmi.chassis.version: lemu2
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrCALPELLACRB.86C.0000.X.0000000000:bd11/11/2010:svnSystem76,Inc.:pnLemurUltraThin:pvrlemu2:rvnSystem76,Inc.:rnLemurUltraThin:rvrlemu2:cvnSystem76,Inc.:ct10:cvrlemu2:
dmi.product.name: Lemur UltraThin
dmi.product.version: lemu2
dmi.sys.vendor: System76, Inc.
version.compiz: compiz 1:0.9.7.6-0ubuntu1
version.libdrm2: libdrm2 2.4.32-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu3
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu10
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

[Michael Terry (mterry)]

Note that if you use "fr" instead, that works. It seems to be something about this variant.

[Bryce Harrington (bryce)]

Probably something higher up the stack than xkeyboard-config, but so far it looks like something to do with an invalid (or unexpected) keyboard configuration.

Michael's already tested with the current upstream fr layout, and found it did not make a difference.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/985065

[Fabio Marconi (fabiomarconi)]

Sorry if disturbing, but is reproducible with russian too
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[Bryce Harrington (bryce)]

Let me see if I'm reproducing everything properly.

I've added the French (alternative) layout as first listed before US.
After rebooting, the indicator menu shows French (alternative) selected.

setxkbmap looks correct:

xkb_keymap {
 xkb_keycodes { include "evdev+aliases(azerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+fr(oss)+us:2+inet(evdev)" };
 xkb_geometry { include "pc(pc105)" };
};

xprop -root | grep XKB looks ok
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "fr", "oss", ""
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "fr,us", "oss,", ""

And gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd shows fr oss:

 options = [terminate terminate:ctrl_alt_bksp]
 layouts = [fr oss,us]

not sure why there's a double-space between 'fr' and 'oss' there. Might be relevant?

Anyway, despite all this the layout behavior is still US-style. For instance, the 'm' key prints an 'm' whereas with fr oss I gather it should be printing an ','.

Then I run sudo dpkg-reconfigure keyboard-configuration. I select "Generic 105-key (Intl) PC", "French", "French - French (alternative)", "The default for the keyboard layout", and "Right Alt (AltGR)" for compose key.

After this, the keyboard seems to be working in fr oss mode. 'm' prints ',' and other keys seem remapped differently. However I notice the indicator menu icon shows 'en' (but clicking on it shows 'French (alternative)' - so that's inconsistent.)

Logging out, the login screen's indicator shows fr/French (alternative). Logging in still shows fr/French (alternative), however checking on a gnome terminal window, 'm' is back to printing 'm' instead of ','

So something is different between what is done when executing dpkg-reconfigure vs. when it's done via gnome. Also, I guess this rules out that there's a simple bug in the keyboard configuration map itself.

Think the next action should be to compare what these two configuration mechanisms do for diffs.

Also, at this point I'm betting it's something ubuntu-specific or debian-specific going on here, so I'm going to hold off forwarding this upstream to suv until we understand it better.

[Bryce Harrington (bryce)]

mterry, btw how did you do debugging messages for libxklavier? Was that just running g-s-d with --debug and --nodaemon, or some other method?

[Bryce Harrington (bryce)]

Aside from running dpkg-reconfigure, hand editing /etc/default/keyboard and then running `sudo udevadm trigger --subsystem-match=input --action=change` also works around the problem.

`setxkbmap fr oss` works around it for the session.

Attached is a script that summarizes some keyboard configuration details.

I'd like to know what X call is producing the error in xklavier, however not sure how to determine that short of inlining printfs or setting up xtrace.

[Bryce Harrington (bryce)]

Baseline (US) keyboard.

[Bryce Harrington (bryce)]

Running `setxkbmap fr oss`:

--- us.txt 2012-04-18 20:03:29.294915791 -0700
+++ fr_oss.txt 2012-04-18 20:03:29.270915721 -0700
@@ -12,7 +12,7 @@ LANGUAGE=en_US:en

 xprop -root | grep XKB
 _XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "us", "", ""
-_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", "compose:ralt"
+_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "fr", "oss", "compose:ralt"

 gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
  options = []
@@ -21,18 +21,18 @@ gconftool-2 -R /desktop/gnome/peripheral

 setxkbmap -print
 xkb_keymap {
- xkb_keycodes { include "evdev+aliases(qwerty)" };
+ xkb_keycodes { include "evdev+aliases(azerty)" };
  xkb_types { include "complete" };
  xkb_compat { include "complete" };
- xkb_symbols { include "pc+us+inet(evdev)+compose(ralt)" };
+ xkb_symbols { include "pc+fr(oss)+inet(evdev)+compose(ralt)" };
  xkb_geometry { include "pc(pc105)" };
 };

 xkbcomp :0 -w0 - | grep ^xkb_
 xkb_keymap {
-xkb_keycodes "evdev+aliases(qwerty)" {
+xkb_keycodes "evdev+aliases(azerty)" {
 xkb_types "complete" {
 xkb_compatibility "complete" {
-xkb_symbols "pc+us+inet(evdev)+compose(ralt)" {
+xkb_symbols "pc+fr(oss)+inet(evdev)+compose(ralt)" {
 xkb_geometry "pc(pc105)" {

[Bryce Harrington (bryce)]

Reverting previous by running `setxkbmap us`, and then using the GUI keyboard config:

--- us.txt 2012-04-18 20:03:29.294915791 -0700
+++ gnome.fr_oss.txt 2012-04-18 20:03:29.274915733 -0700
@@ -12,27 +12,27 @@ LANGUAGE=en_US:en

 xprop -root | grep XKB
 _XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "us", "", ""
-_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", "compose:ralt"
+_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "fr,us", "oss,", ""

 gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
  options = []
- layouts = [us]
+ layouts = [fr oss,us]
  model =

 setxkbmap -print
 xkb_keymap {
- xkb_keycodes { include "evdev+aliases(qwerty)" };
+ xkb_keycodes { include "evdev+aliases(azerty)" };
  xkb_types { include "complete" };
  xkb_compat { include "complete" };
- xkb_symbols { include "pc+us+inet(evdev)+compose(ralt)" };
+ xkb_symbols { include "pc+fr(oss)+us:2+inet(evdev)" };
  xkb_geometry { include "pc(pc105)" };
 };

 xkbcomp :0 -w0 - | grep ^xkb_
 xkb_keymap {
-xkb_keycodes "evdev+aliases(qwerty)" {
+xkb_keycodes "evdev+aliases(azerty)" {
 xkb_types "complete" {
 xkb_compatibility "complete" {
-xkb_symbols "pc+us+inet(evdev)+compose(ralt)" {
+xkb_symbols "pc+fr(oss)+us:2+inet(evdev)" {
 xkb_geometry "pc(pc105)" {

With these settings, the keyboard isn't set to fr oss but rather to us.

[Bryce Harrington (bryce)]

Difference between the above two:

--- us_diff_fr_oss.txt 2012-04-18 20:06:56.015521896 -0700
+++ us_diff_gnome_fr_oss.txt 2012-04-18 20:07:11.255566849 -0700
@@ -1,15 +1,17 @@
 --- us.txt 2012-04-18 20:03:29.294915791 -0700
-+++ fr_oss.txt 2012-04-18 20:03:29.270915721 -0700
-@@ -12,7 +12,7 @@ LANGUAGE=en_US:en
++++ gnome.fr_oss.txt 2012-04-18 20:03:29.274915733 -0700
+@@ -12,27 +12,27 @@ LANGUAGE=en_US:en

  xprop -root | grep XKB
  _XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "us", "", ""
 -_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", "compose:ralt"
-+_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "fr", "oss", "compose:ralt"
++_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "fr,us", "oss,", ""

  gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
   options = []
-@@ -21,18 +21,18 @@ gconftool-2 -R /desktop/gnome/peripheral
+- layouts = [us]
++ layouts = [fr oss,us]
+ model =

  setxkbmap -print
  xkb_keymap {
@@ -18,7 +20,7 @@
   xkb_types { include "complete" };
   xkb_compat { include "complete" };
 - xkb_symbols { include "pc+us+inet(evdev)+compose(ralt)" };
-+ xkb_symbols { include "pc+fr(oss)+inet(evdev)+compose(ralt)" };
++ xkb_symbols { include "pc+fr(oss)+us:2+inet(evdev)" };
   xkb_geometry { include "pc(pc105)" };
  };

@@ -29,6 +31,6 @@
  xkb_types "complete" {
  xkb_compatibility "complete" {
 -xkb_symbols "pc+us+inet(evdev)+compose(ralt)" {
-+xkb_symbols "pc+fr(oss)+inet(evdev)+compose(ralt)" {
++xkb_symbols "pc+fr(oss)+us:2+inet(evdev)" {
  xkb_geometry "pc(pc105)" {

[Bryce Harrington (bryce)]

Forwarding this bug from Ubuntu reporter Michael Terry:
http://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/985065

[Problem]
In Ubuntu, using the GUI capplet to add a new default layout does not actually change the key mappings. A libxklavier error from X is seen.

[Original Description]
This is a break-out bug from bug 960096.

When you have fr/oss "French (alternative)" layout as your first layout, you end up with "us" instead.

If you enable libxklavier debugging output, you'll see the following in your logs:

"Unexpected by libxklavier X ERROR: 0x8351fb8, 163f0005, 2 [], X11 request: 145, minor code: 9"

                xkl_debug(200,
                          "Unexpected by libxklavier X ERROR: %p, "
                          WINID_FORMAT ", %d [%s], "
                          "X11 request: %d, minor code: %d\n", dpy,
                          (unsigned long) evt->resourceid,
                          (int) evt->error_code, buf,
                          (int) evt->request_code, (int) evt->minor_code);

That 2 in there is the X error code, which means _XkbErrMissingTypes for xkbfile extension. I assume 145 is the major op code that got assigned for the XKBFile extension. If so, 9 is the X_kbSetMap request. Which all fits with an error trying to set the new layout map.

DistroRelease: Ubuntu 12.04
Package: xorg 1:7.6+12ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-23.36-generic-pae 3.2.14
Uname: Linux 3.2.0-23-generic-pae i686
.tmp.unity.support.test.0:

ApportVersion: 2.0.1-0ubuntu4
Architecture: i386
CheckboxSubmission: 9a284f3f6b4f7829abbe27ad9573a709
CheckboxSystem: 3935143777c965daaa64b51f0134f712
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
CompositorRunning: compiz
Date: Wed Apr 18 12:31:05 2012
DistUpgraded: 2011-11-05 19:49:52,977 DEBUG enabling apt cron job
DistroCodename: precise
DistroVariant: ubuntu
DkmsStatus: virtualbox, 4.1.12, 3.2.0-23-generic-pae, i686: installed
EcryptfsInUse: Yes
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 18) (prog-if 00 [VGA controller])
Subsystem: CLEVO/KAPOK Computer Device [1558:3100]
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release i386 (20110422)
Lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
MachineType: System76, Inc. Lemur UltraThin
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic-pae root=UUID=0e585e80-16f1-404c-80cc-7d9805fcc3b0 ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: Upgraded to precise on 2011-11-05 (164 days ago)
dmi.bios.date: 11/11/2010
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: CALPELLACRB.86C.0000.X.0000000000
dmi.board.asset.tag: Tag 12345
dmi.board.name: Lemur UltraThin
dmi.board.vendor...

[Bryce Harrington (bryce)]

Let me see if I'm reproducing everything properly.

I've added the French (alternative) layout as first listed before US.
After rebooting, the indicator menu shows French (alternative) selected.

setxkbmap looks correct:

xkb_keymap {
 xkb_keycodes { include "evdev+aliases(azerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+fr(oss)+us:2+inet(evdev)" };
 xkb_geometry { include "pc(pc105)" };
};

xprop -root | grep XKB looks ok
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "fr", "oss", ""
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "fr,us", "oss,", ""

And gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd shows fr oss:

 options = [terminate terminate:ctrl_alt_bksp]
 layouts = [fr oss,us]

not sure why there's a double-space between 'fr' and 'oss' there. Might be relevant?

Anyway, despite all this the layout behavior is still US-style. For instance, the 'm' key prints an 'm' whereas with fr oss I gather it should be printing an ','.

Then I run sudo dpkg-reconfigure keyboard-configuration. I select "Generic 105-key (Intl) PC", "French", "French - French (alternative)", "The default for the keyboard layout", and "Right Alt (AltGR)" for compose key.

After this, the keyboard seems to be working in fr oss mode. 'm' prints ',' and other keys seem remapped differently. However I notice the indicator menu icon shows 'en' (but clicking on it shows 'French (alternative)' - so that's inconsistent.)

Logging out, the login screen's indicator shows fr/French (alternative). Logging in still shows fr/French (alternative), however checking on a gnome terminal window, 'm' is back to printing 'm' instead of ','

Aside from running dpkg-reconfigure, hand editing /etc/default/keyboard and then running `sudo udevadm trigger --subsystem-match=input --action=change` also works around the problem.

`setxkbmap fr oss` works around it for the session.

Attached is a script that summarizes some keyboard configuration details.

[Bryce Harrington (bryce)]

Created attachment 60291
kbd-debug

[Bryce Harrington (bryce)]

See the LP bug for two runs of the above tool. It appears that the difference between doing the change using setxkbmap and the GUI tool is:

@@ -18,7 +20,7 @@
   xkb_types { include "complete" };
   xkb_compat { include "complete" };
 - xkb_symbols { include "pc+us+inet(evdev)+compose(ralt)" };
-+ xkb_symbols { include "pc+fr(oss)+inet(evdev)+compose(ralt)" };
++ xkb_symbols { include "pc+fr(oss)+us:2+inet(evdev)" };
   xkb_geometry { include "pc(pc105)" };
  };

@@ -29,6 +31,6 @@
  xkb_types "complete" {
  xkb_compatibility "complete" {
 -xkb_symbols "pc+us+inet(evdev)+compose(ralt)" {
-+xkb_symbols "pc+fr(oss)+inet(evdev)+compose(ralt)" {
++xkb_symbols "pc+fr(oss)+us:2+inet(evdev)" {
  xkb_geometry "pc(pc105)" {

However, I'm not certain of the significance of these values.

[Bryce Harrington (bryce)]

Note that we're carrying a few patches in Ubuntu which may (or may not) be relevant:

To xklavier:
 * we're reverting one change via revert-default-group-change.patch
   (See https://bugs.freedesktop.org/show_bug.cgi?id=47671)
 * Carrying one upstream patch, backport of commit 28cb7b7e
   (See https://bugs.freedesktop.org/show_bug.cgi?id=46416)

To gnome-settings-daemon:
  * Complete list: http://paste.ubuntu.com/936362/
  * ...
  * 61_unity_use_application_indicator.patch
  * revert_git_stop_using_gconf.patch
  * revert_git_use_gsetting_keybindings.patch

[Bryce Harrington (bryce)]

Note that while this can be reproduced using fr oss, it seems other keyboard layouts are affected. I haven't exhaustively tested all of them, but enough to see it's a larger issue than just a bug with fr oss.

[Sergey V. Udaltsov (svu)]

> not sure why there's a double-space between 'fr' and 'oss' there. Might be
relevant?
It is not a double space, it is a tab char IIRC.

> ++ xkb_symbols { include "pc+fr(oss)+us:2+inet(evdev)" };
g-s-d always adds "system" layout - from gdm. So if your gdm has 'us' layout, it is added as a 2nd one. I just wonder where you lost the compose(ralt) option...

Could you please attach 2 results:

1. Configure fr(oss) in normal gnome way, add 'us' as a 2nd layout (all through GUI). Then, do xkbcomp :0 -xkb out_gnome.xkb

2. Just do "setxkbmap -layout fr,us -variant oss, -option Then, do xkbcomp :0 -xkb out_manual.xkb

I want to compare the files

[Bryce Harrington (bryce)]

Created attachment 60403
out_gnome.xkb

[Bryce Harrington (bryce)]

Created attachment 60404
out_manual.xkb

[Øyvind Stegard (oyvindstegard)]

Same problems with Norwegian keyboard layout. It won't set properly after configuration, and en-US layout is used in practice (even though indicator says No[rwegian]).

[Sergey V. Udaltsov (svu)]

Thank you! They are amazing! The out_gnome.xkb shows something unbelievable:

> xkb_symbols "pc+fr(oss)+us:2+inet(evdev)" {

So, I would expect 1st group being fr(oss) and 2nd group us. But in reality that is the other way aroung... :(

Could you please set XKL_DEBUG=200, restart g-s-d and then capture stdout of g-s-d. It should should the keymap file it produces (somewhere in /tmp) and keep that file. After that, I would be interested in getting that keymap file.

[Bryce Harrington (bryce)]

Created attachment 60506
stdout

Not sure I did this correctly, as I didn't find any files created in /tmp after restarting gsd, however here is the stdout from killing it and then running /usr/lib/gnome-settings-daemon/gnome-settings-daemon

[Bryce Harrington (bryce)]

At this stage we don't know for 100% certain whether the root cause is a general problem affecting many keyboard layouts, or is due to something specific with fr/oss that just happens to show a generic symptom that other keyboard layouts also exhibit.

However, if it is the latter, then the stack should be stronger at communicating those issues up so they can be more readily debugged.

[Steve Langasek (vorlon)]

Release note added to https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop:

 * When using the LiveCD in certain languages such as French and choosing "Try Ubuntu" at the prompt, the keyboard will be brought up with the US keyboard map instead of the correct one for the chosen language. To avoid this bug, users can press any key at the very first splash screen and select their language here instead. (Bug:985065)

[Sergey V. Udaltsov (svu)]

I guess, you rerun g-s-d in the same session, right? In that case g-s-d did not have to configure the keyboard - because it was already tuned to the same config. Would you be able to run g-s-d at the session startup with XKL_DEBUG=200 - so it would actually have to change XKB configuration? In that case, something should appear in /tmp

[Bryce Harrington (bryce)]

Created attachment 60914
Xorg.0.log

Forcing recompilation of the xkb keymaps...

[Bryce Harrington (bryce)]

Created attachment 60915
server-3B1E7EC017335DF19FF0A1742B988209FD2FAB9E.xkm

[Bryce Harrington (bryce)]

Created attachment 60916
server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm

[Bryce Harrington (bryce)]

Looking at the code, no intermediate .xkb file is created to disk; it's passed directly from memory to xkbcomp.

Btw, if you want to experiment more directly, you can snag ubuntu-12.04-dvd-i386.iso.torrent (or ubuntu-12.04-dvd-i386.iso) from http://cdimage.ubuntu.com/releases/12.04/release/ and burn to a USB stick using USB disk creator).

[Sergey V. Udaltsov (svu)]

Unfortunately both xkm files are useless - they contain single us group ("xkbcomp foobar.xkm -xkb out.xkb").

Regarding the keymap file, in libxklavier:

                                                if (xkl_debug_level < 500) { /* don't remove on high debug levels! */
                                                        if (remove(xkm_fn)

So I was wrong - the file stays with debug level > 500.

But it really looks like a bug in Xorg server - it is against any rules, to switch the groups. out_gnome.xkb IMNSHO clearly indicates that.

[Øsse (oystwa)]

I experience this bug as well. I chose "Install Ubuntu" at the very first prompt when booting the CD. During the installation I chose Norwegian as my layout and tested that this worked. After booting (every boot) the keyboard layout is apparently US English.

At the login screen Norwegian is set as the keyboard layout and is the only alternative. In Gnome Control Center the keyboard layout is Norwegian. The output of 'setxkbmap -query -v' is

    Trying to build keymap using the following components:
    keycodes: evdev+aliases(qwerty)
    types: complete
    compat: complete
    symbols: pc+no+inet(evdev)
    geometry: pc(pc105)
    rules: evdev
    model: pc105
    layout: no

If I add e.g. Swedish or Danish in Gnome Control Center and put that layout on top the layout is immediately changed. Putting Norwegian back on top does nothing, even after removing the others. Note that it does _not_ go back to US English; it's simply unchanged.

If I run 'setxkbmap no' the layout is immediately changed to Norwegian. The output of 'setxkbmap -query -v' does not change nor does the output of 'xprop -root | grep XKB'

[Raymond Brun (raymond-brun)]

I have this problem with norwegian keyboard. Running 12.04 clean install from ISO a week after the release, so I guess it is the same version as people above reports.

When I choose keyboard language from GUI it seems to change, but it sticks to US.
A workaround that works is that I do this:
sudo setxkbmap -option grp:alt_shift_toggle no,us,se

That allows me using keyboard for quite some time, a few hours. Then norwegian keyboard suddenly disappears. Then I have to run the command again. That forgetting keyboartd issue looks like a few bugs named "Ubuntu forgets keyboard language USB".

I have both problems.

[Øyvind Stegard (oyvindstegard)]

Raymond Brun <email address hidden> writes:

> That allows me using keyboard for quite some time, a few hours. Then
> norwegian keyboard suddenly disappears. Then I have to run the command
> again. That forgetting keyboartd issue looks like a few bugs named
> "Ubuntu forgets keyboard language USB".

Same here, I find myself thinking: "Hmm, didn't I just reset the
keyboard to Norwegian ? Why is it English again now ?". Have wireless
keyboard with USB dongle.

[Sebastien Bacher (seb128)]

Not sure if I got it right but I got 2 files in /tmp here

* one text file with

"xkb_keymap {
        xkb_keycodes { include "evdev+aliases(azerty)" };
        xkb_types { include "complete" };
        xkb_compat { include "complete" };
        xkb_symbols { include "pc+fr(oss)+gb:2+inet(evdev)+group(shift_caps_toggle)" };
        xkb_geometry { include "pc(pc105)" };
};"

and one binary which I'm adding next

[Sebastien Bacher (seb128)]

Created attachment 61755
g-s-d generated file

the layout configured at fr (oss) by default and english (uk)

[Sebastien Bacher (seb128)]

let me know if you need extra details, that bug is really annoying since it means french users can't change their layout using keybindings or the applet,indicator, using setxkbmap works though

[Sergey V. Udaltsov (svu)]

To me it looks like a bug in the server. Look at the file out_gnome.xkb provided by bryce:

...
xkb_symbols "pc+fr(oss)+us:2+inet(evdev)" {
...
    key <AD01> {
        type[group1]= "ALPHABETIC",
        type[group2]= "FOUR_LEVEL_ALPHABETIC",
        symbols[Group1]= [ q, Q ],
        symbols[Group2]= [ a, A, ae, AE ]
    };
...
So, symbols are screwed, fr is supposed to be in the 1st group, but in reality they are in the second group (American Qwerty vs French A)

At the same time, the xkm file attached by Sebastien, once converted to xkb ("xkbcomp in.xkm -xkb out.xkb") has:
...
xkb_symbols "pc+fr(oss)+gb:2+inet(evdev)+group(shift_caps_toggle)" {
...
    key <AD01> {
        type[group1]= "FOUR_LEVEL_ALPHABETIC",
        type[group2]= "FOUR_LEVEL_SEMIALPHABETIC",
        symbols[Group1]= [ a, A, ae, AE ],
        symbols[Group2]= [ q, Q, at, Greek_OMEGA ]
    };
...
Which is correct! So, once that xkm file is fed into X server, it swaps the groups. At least that's the only explanation I can give, for now. If everyone agrees with that, I would forward that bug to xorg server, Input/XKB component. If someone has better ideas - please let me hear them!

[Sebastien Bacher (seb128)]

Sergey, reassigning works for me, I don't know enough about X handling of keyboards layouts to have an opinion on whether the bug is in the server or in the lib

[Sebastien Bacher (seb128)]

Created attachment 61788
out_gnome.xkb

Since I'm not sure I've the same config that Bryce I'm attaching the xkb output files from my config as well, they look different

[Sebastien Bacher (seb128)]

Created attachment 61789
the manual one

[Sebastien Bacher (seb128)]

Created attachment 61793
the same gb instead of us

since that's the keymap configured here (fr oss, gb)

[Sebastien Bacher (seb128)]

Downgrading libxklavier, libgnomekbd and gnome-settings-daemon to the oneiric version doesn't fix the bug which would confirm the issue is not coming from those but rather from xorg

[Bryce Harrington (bryce)]

Keyboard-related patches in Ubuntu's xserver:

13_debian_add_xkbpath_env_variable.diff
   http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=blob_plain;f=debian/patches/13_debian_add_xkbpath_env_variable.diff;hb=refs/heads/ubuntu

190_cache-xkbcomp_output_for_fast_start_up.patch
   http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=blob_plain;f=debian/patches/190_cache-xkbcomp_output_for_fast_start_up.patch;hb=refs/heads/ubuntu

208_switch_on_release.diff
   http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=blob_plain;f=debian/patches/208_switch_on_release.diff;hb=refs/heads/ubuntu

On the theory that the bug is in the server, next step is probably to try with each of these patches disabled in turn. 190 directly affects xkbcomp loading so would be the one to test first.

[Bryce Harrington (bryce)]

Tested with 190 disabled, but still same fault.

While patch 208 is a keyboard patch, it really has nothing to do with this.

Patch 13 is from debian and is quite ancient (from 2006), so doubting that's going to be the cause of all this.

So, if this is indeed an xserver bug, I think it may be reproducible in the upstream codebase. Guessing that's the next step...

[Øyvind Stegard (oyvindstegard)]

Same symptons on two different Ubuntu 12.04 installations now (one installed from scratch with alternate install CD), where the only relevant thing in common is that they both use USB/Bluetooth keyboards. Another install on a laptop does not exhibit this problem of wrong keyboard layout. Simplest work-around so far is "setxkbmap no" after session has started ..

[Fabio Marconi (fabiomarconi)]

Hello
Is this fixed in Quantal ???
Steps done:
ubiquity propose timezone italian exactly, propose italian layout exactly (i've got an italian keyboard and i'm in Italy), accept french layout, in the installed system i've an azerty keyboard (french layout) as expected.
In gnome control center -> keyboard, clicking on reset to default it still French.
All in real hardware.

[Sebastien Bacher (seb128)]

Daniel, is there any chance you could look at that issue?

[Sebastien Bacher (seb128)]

Ok, so as an additional piece of info the issue happens as well on a fedora 17 liveCD so it's not an Ubuntu patch or an issue specific to a distro

[Bryce Harrington (bryce)]

@seb, do you have a bug ref. for the fedora 17 issue?

[Sebastien Bacher (seb128)]

@bryce: no, I tested the same steps on a f17 liveCD myself and commented there, do you think it warrants a new report?

[Jean-Alexandre Anglès d'Auriac (jagw40k)]

This seems very similar to bug 43541
https://bugs.freedesktop.org/show_bug.cgi?id=43541
Is this not the same bug ? I had the exact same symptoms.

[Sebastien Bacher (seb128)]

The patch from https://bugs.freedesktop.org/show_bug.cgi?id=43541#c12 fixes the issue indeed

[Sebastien Bacher (seb128)]

ok, upstream got a patch on https://bugs.freedesktop.org/show_bug.cgi?id=43541, I've tested it here and it does fix the fr oss case!

[Launchpad Janitor (janitor)]

This bug was fixed in the package xkeyboard-config - 2.5-1ubuntu5

---------------
xkeyboard-config (2.5-1ubuntu5) quantal; urgency=low

  * Add 113_ossmath_is_five_levels.patch: Some keymaps like fr/oss fail to
    load because they include ossmath (via keypad(oss)) which
    misconfigures the keypad as 4-level when it should be 5-level. This
    patch from upstream bugzilla fixes this by adding the 5th level to the
    ossmath definition.
    (LP: #985065)
 -- Bryce Harrington <email address hidden> Mon, 25 Jun 2012 09:30:19 -0700

[Sebastien Bacher (seb128)]

closing, the patch from the other bug fixes the issue and got commited

[Chris Halse Rogers (raof)]

Hello Michael, or anyone else affected,

Accepted xkeyboard-config into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/xkeyboard-config/2.5-1ubuntu1.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[LordPhoenix (lorphoenix)]

Fixed for me. Couldn't switch between fr-bepo and fr-oss but now it's ok

Thanks for all…

[Stéphane Graber (stgraber)]

Updating tag based on that last comment. Thanks for testing.

[Stéphane Graber (stgraber)]

paalfe: Package is still in proposed so the status needs to be "Fix commited". Launchpad will automatically change it to "Fix released" when it's available to everyone.

[Pål F. Kristiansen (paalfe)]

I did not mean to change the status, but I did manage to change it, sorry for that... Tried to change it back, but couldn't.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xkeyboard-config - 2.5-1ubuntu1.3

---------------
xkeyboard-config (2.5-1ubuntu1.3) precise-proposed; urgency=low

  * Add 113_ossmath_is_five_levels.patch: Some keymaps like fr(oss) fail to
    load because they include ossmath (via keypad(oss)) which
    misconfigures the keypad as 4-level when it should be 5-level. This
    patch from upstream bugzilla fixes this by adding the 5th level to the
    ossmath definition.
    (LP: #985065)
  * Drop 109_fr_oss_space_char.patch change; the fix causes behavioral
    changes for right control which a fr(oss) user did not like.
    (LP: #1013881)

xkeyboard-config (2.5-1ubuntu1.2) precise-proposed; urgency=low

  * Add 111_cz_ssharp.patch: Fix mapping of 4th level of the AC11 key to
    ssharp rather than quotedbl for the Czech layout. Cherrypick of
    patch from upstream.
    (LP: #953477)
  * Add 112_dk_dvorak_tilde.patch: Fix tilde key in the Danish Dvorak
    layout. It's not the same as Norwegian as has been assumed previously.
    (LP: #989626)

xkeyboard-config (2.5-1ubuntu1.1) precise-proposed; urgency=low

  * Add 109_fr_oss_space_char.patch: Fix problems using space bar in various
    applications when using the fr(oss) keymap.
    (was for LP bug 221112)
  * Add 110_dead_hook_horn.patch: Add two deadkeys on level 3 and 4 of the
    j key for the latin keymap.
    (LP: #825624)
 -- Bryce Harrington <email address hidden> Mon, 25 Jun 2012 17:32:15 -0700

[Øyvind Stegard (oyvindstegard)]

I still get wrong layout in guest sessions. E.g. Norwegian is set correctly in prefs for guest (as its system default) , but US is actually active and typing is broken. So still need "setxbkmap no" in guest sessions ..

[Alexey Stulov (kinos-pro)]

Same problem. Ubuntu 12.04, lenovo thinkpad t530.

Last update crashed down at first start. Then it updated the system and after reboot i have same problem.

I've tried to remove my native keyboard layout and after adding it back i see in preview screen english letters instead of my native letters. Then i tried to add any other languages(not my native and english) - same reaction. Every time it was english layout.

So i went to system language menu and saw a warning "not all language packs were installed". After Ok and installation process bar i saw the same as always the list with my native and english languages at the top of the list. Everything seems to be alright. But keyboard layout never switches.

Will it be fixed some day?

[Orestis Gorgas (orestis-gorgas)]

workaround : running ' setxkbmap -option grp:alt_shift_toggle no,ca' after login. where no, ca the languages you want to use. You can put the command at the end of .bashrc file.

From :https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/995401

[Tazir (tazir)]

Using Ubuntu Gnome 13.10 (fresh install), with English + Hebrew keyboards.
Still have the same problem - mostly changing the layout (in the indicator and by keyboard shortcut) not working.
Some time its just work.

[Luiz Angelo Daros de Luca (luizluca)]

I didn't had problems with layout until upgrade to 13.10.

The default keyboard layout is "abnt2 (br)/Português (Brasil)" and I have a second layout for "Inglês (EUA)/English us_intl". Even with the trayicon showing "Pt", what I really get is "us_intl" layout. If I select the already selected "Português (Brasil)" in the keyboard layout tray icon submenu, it changes to the correct layout.

[Thorben Dahl (thorbendahl)]

I'm suddenly experiencing this problem too on Ubuntu 13.10, with a Norwegian keyboard. No problems during login, only after logging in.