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.

Created attachment 60291 [details]
kbd-debug

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.

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

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.

> 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

Created attachment 60403 [details]
out_gnome.xkb

Created attachment 60404 [details]
out_manual.xkb

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.

Created attachment 60506 [details]
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

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

Created attachment 60914 [details]
Xorg.0.log

Forcing recompilation of the xkb keymaps...

Created attachment 60915 [details]
server-3B1E7EC017335DF19FF0A1742B988209FD2FAB9E.xkm

Created attachment 60916 [details]
server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm

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

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.

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

Created attachment 61755 [details]
g-s-d generated file

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

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

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!

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

Created attachment 61788 [details]
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

Created attachment 61789 [details]
the manual one

Created attachment 61793 [details]
the same gb instead of us

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

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

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.

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

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

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

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

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

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.

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

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