Bug 48905 - Can't use fr/oss keyboard layout by default
Summary: Can't use fr/oss keyboard layout by default
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/XKB (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Daniel Stone
QA Contact: Xorg Project Team
Depends on:
Reported: 2012-04-18 20:12 UTC by Bryce Harrington
Modified: 2012-06-28 05:28 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

kbd-debug (1.02 KB, application/octet-stream)
2012-04-18 20:13 UTC, Bryce Harrington
no flags Details
out_gnome.xkb (65.87 KB, text/plain)
2012-04-20 11:59 UTC, Bryce Harrington
no flags Details
out_manual.xkb (64.15 KB, text/plain)
2012-04-20 11:59 UTC, Bryce Harrington
no flags Details
stdout (68.00 KB, text/plain)
2012-04-23 21:01 UTC, Bryce Harrington
no flags Details
Xorg.0.log (34.59 KB, text/x-log)
2012-05-02 11:00 UTC, Bryce Harrington
no flags Details
server-3B1E7EC017335DF19FF0A1742B988209FD2FAB9E.xkm (11.00 KB, application/octet-stream)
2012-05-02 11:00 UTC, Bryce Harrington
no flags Details
server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm (10.99 KB, application/octet-stream)
2012-05-02 11:01 UTC, Bryce Harrington
no flags Details
g-s-d generated file (14.15 KB, application/octet-stream)
2012-05-17 10:48 UTC, Sebastien Bacher
no flags Details
out_gnome.xkb (60.00 KB, application/octet-stream)
2012-05-18 03:51 UTC, Sebastien Bacher
no flags Details
the manual one (64.15 KB, application/octet-stream)
2012-05-18 03:51 UTC, Sebastien Bacher
no flags Details
the same gb instead of us (65.28 KB, application/octet-stream)
2012-05-18 04:22 UTC, Sebastien Bacher
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bryce Harrington 2012-04-18 20:12:11 UTC
Forwarding this bug from Ubuntu reporter Michael Terry:

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"

                          "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

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
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)
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:
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
Comment 1 Bryce Harrington 2012-04-18 20:12:59 UTC
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.
Comment 2 Bryce Harrington 2012-04-18 20:13:18 UTC
Created attachment 60291 [details]
Comment 3 Bryce Harrington 2012-04-18 20:15:01 UTC
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.
Comment 4 Bryce Harrington 2012-04-18 20:24:15 UTC
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
Comment 5 Bryce Harrington 2012-04-18 20:26:54 UTC
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.
Comment 6 Sergey V. Udaltsov 2012-04-19 06:24:52 UTC
> not sure why there's a double-space between 'fr' and 'oss' there. Might be
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
Comment 7 Bryce Harrington 2012-04-20 11:59:05 UTC
Created attachment 60403 [details]
Comment 8 Bryce Harrington 2012-04-20 11:59:18 UTC
Created attachment 60404 [details]
Comment 9 Sergey V. Udaltsov 2012-04-21 10:10:01 UTC
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.
Comment 10 Bryce Harrington 2012-04-23 21:01:37 UTC
Created attachment 60506 [details]

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
Comment 11 Sergey V. Udaltsov 2012-04-28 16:34:42 UTC
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
Comment 12 Bryce Harrington 2012-05-02 11:00:42 UTC
Created attachment 60914 [details]

Forcing recompilation of the xkb keymaps...
Comment 13 Bryce Harrington 2012-05-02 11:00:59 UTC
Created attachment 60915 [details]
Comment 14 Bryce Harrington 2012-05-02 11:01:19 UTC
Created attachment 60916 [details]
Comment 15 Bryce Harrington 2012-05-02 11:26:14 UTC
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).
Comment 16 Sergey V. Udaltsov 2012-05-02 16:43:52 UTC
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.
Comment 17 Sebastien Bacher 2012-05-17 10:47:10 UTC
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
Comment 18 Sebastien Bacher 2012-05-17 10:48:22 UTC
Created attachment 61755 [details]
g-s-d generated file

the layout configured at fr (oss) by default and english (uk)
Comment 19 Sebastien Bacher 2012-05-17 10:49:27 UTC
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
Comment 20 Sergey V. Udaltsov 2012-05-17 16:03:17 UTC
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!
Comment 21 Sebastien Bacher 2012-05-18 03:46:11 UTC
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
Comment 22 Sebastien Bacher 2012-05-18 03:51:03 UTC
Created attachment 61788 [details]

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
Comment 23 Sebastien Bacher 2012-05-18 03:51:24 UTC
Created attachment 61789 [details]
the manual one
Comment 24 Sebastien Bacher 2012-05-18 04:22:16 UTC
Created attachment 61793 [details]
the same gb instead of us

since that's the keymap configured here (fr oss, gb)
Comment 25 Sebastien Bacher 2012-05-18 04:32:30 UTC
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
Comment 26 Bryce Harrington 2012-06-01 12:59:59 UTC
Keyboard-related patches in Ubuntu's xserver:




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.
Comment 27 Bryce Harrington 2012-06-01 14:48:44 UTC
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...
Comment 28 Sebastien Bacher 2012-06-13 06:03:04 UTC
Daniel, is there any chance you could look at that issue?
Comment 29 Sebastien Bacher 2012-06-15 05:42:21 UTC
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
Comment 30 Bryce Harrington 2012-06-15 10:18:41 UTC
@seb, do you have a bug ref. for the fedora 17 issue?
Comment 31 Sebastien Bacher 2012-06-18 08:06:20 UTC
@bryce: no, I tested the same steps on a f17 liveCD myself and commented there, do you think it warrants a new report?
Comment 32 Jean-Alexandre Anglès d'Auriac 2012-06-23 06:44:14 UTC
This seems very similar to bug 43541
Is this not the same bug ? I had the exact same symptoms.
Comment 33 Sebastien Bacher 2012-06-25 07:25:58 UTC
The patch from https://bugs.freedesktop.org/show_bug.cgi?id=43541#c12 fixes the issue indeed
Comment 34 Sebastien Bacher 2012-06-28 05:28:04 UTC
closing, the patch from the other bug fixes the issue and got commited

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.