Testing again - this is independent of pressing any modifier keys - my default keyboard map on first-boot/auto-login is something very strange; having logged out & in again manually all is well - very strange.

I attach the process tree at initial login (in case it helps).

Created attachment 201537 [details]
processes

Unable to duplicate this.

Still occuring for me on every restart with factory :-)
Once I log out & in again, all is good; really not wonderful.

Still unable to duplicate, but maybe related to bug 373197    	

This looks like we have a stuck 'Alt-Gr' but only on boot.

I wonder if it's an X bug ... ;-)

Mmmh, okay, since Michael moved the bug to X, I'm going to reassign the bug. If you move it back to GNOME, feel free to assign it back to me ;-)

Please do the following for both cases - autologin and after logout+login.

  xkbcomp $DISPLAY <file.xkb>

Any error messages when running this command? Please attach the xkb files. Then  I can diff them. Does running 

  setxkbmap -print | xkbcomp - $DISPLAY

fix the issue? Then it's a duplicate of Bug #368673.

Your 2nd command fixed it => marking a duplicate.
An impressively stupid workaround ;-) is there a good fix in the works ?
Thanks...

*** This bug has been marked as a duplicate of bug 368673 ***

Yes, I know that it is a stupid workaroud.

There's no good fix in the works now. I considered to report it upstream, but since I was sure it would be ignored like any other issue, which pops up at the moment, I decided not to report it. And then I felt we had already lost enough time on this. Seriously, if you look at the bugreport ...

Oh dear. Having up-graded I tested with this fix; and lo ! having clicked 'Computer' and started typing in the search bar - imagine my joy to discover all was well on 1st time login.

Amazingly though - as I started to interact with nautilus, launched a gnome-terminal and started typing: I got random stuck-Alt-Gr text [!].

Interestingly, the whole desktop was then hosed stuck-key-wise.

It's -extremely- odd that this should happen during the login process (presumably some late-starting thing breaks everything later ?). Could it be gnome-settings-daemon causing the grief ?

Interesting - so; having been 100% repeatable - I renamed gnome-settings-daemon to "not-gnome-settings-daemon" (meaning it didn't start), and bingo : I don't have the problem anymore.

Quite why it should behave thus is a mystery to me though.

So it's a gnome-settings-daemon issue. Reassigning.

See bug #373197 for another bug related to keymap hotkeys.

Michael: hopefully, setting /apps/gnome_settings_daemon/plugins/keyboard/active to false is enough to "fix" this? If yes, then it's a bug in this plugin, libgnomekbd or somewhere lower... I remember seeing this bug too, btw, although I can't easily reproduce this...

Michael: can you also dump your gconf config living under /desktop/gnome/peripherals/keyboard? Thanks :-)

Oh, and while I'm at it, do you see something special in xev?
(I know, I know, many questions :-))

Created attachment 212640 [details]
keyboard gconf settings dump

attached keyboard gconf settings.
Running xev and press/releasing 'AltGr' then "h" "i" gives me:


KeyPress event, serial 33, synthetic NO, window 0x3a00001,
    root 0x4c, subw 0x0, time 255323, (47,80), root:(89,495),
    state 0x2000, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3a00001,
    root 0x4c, subw 0x0, time 255395, (47,80), root:(89,495),
    state 0x2080, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x3a00001,
    root 0x4c, subw 0x0, time 270091, (47,80), root:(89,495),
    state 0x2000, keycode 43 (keysym 0x2b1, hstroke), same_screen YES,
    XLookupString gives 2 bytes: (c4 a7) "#"
    XmbLookupString gives 2 bytes: (c4 a7) "#"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3a00001,
    root 0x4c, subw 0x0, time 270138, (47,80), root:(89,495),
    state 0x2000, keycode 43 (keysym 0x2b1, hstroke), same_screen YES,
    XLookupString gives 2 bytes: (c4 a7) "#"
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x3a00001,
    root 0x4c, subw 0x0, time 272285, (47,80), root:(89,495),
    state 0x2000, keycode 31 (keysym 0x8fd, rightarrow), same_screen YES,
    XLookupString gives 3 bytes: (e2 86 92) "#"
    XmbLookupString gives 3 bytes: (e2 86 92) "#"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3a00001,
    root 0x4c, subw 0x0, time 272348, (47,80), root:(89,495),
    state 0x2000, keycode 31 (keysym 0x8fd, rightarrow), same_screen YES,
    XLookupString gives 3 bytes: (e2 86 92) "#"
    XFilterEvent returns: False

HTH.

The problem is "obviously" caused by state 0x2000.
0x2000 is (1 << 13).

According to gdktypes.h:

  /* The next few modifiers are used by XKB, so we skip to the end.
   * Bits 15 - 25 are currently unused. Bit 29 is used internally.
   */

(where next means "what's after 12"). A quick look at the masks defined in X.h seems to confirm this -- the last mask I can find there is:

#define Button5Mask		(1<<12)

I'm currently trying to decrypt the xkb headers to find what is (1 << 13).

having disabled the plugins/keyboard thing I boot and my keyboard works fine: so I guess this isolates it to somewhere close to gnome-settings-daemon's keyboard config and/or the X server, or some interaction therein.

I'm trying a re-boot with a clean user account to isolate strangeness in my config.

clean account with the gconf settings from /desktop/gnome/peripherals/keyboard loaded yields the same broken behavior :-)
So - if I'm bored enough - this should be susceptible to binary chop ... ;-)

(In reply to comment #20 from Michael Meeks)
> having disabled the plugins/keyboard thing I boot and my keyboard works fine:
> so I guess this isolates it to somewhere close to gnome-settings-daemon's
> keyboard config and/or the X server, or some interaction therein.

Okay, I'm going to be a parrot and just repeat what Sergey tells me :-)

14:46 < svu> could he disable the plugin - BUT put absolutely same XKB configuration into xorg.conf?
14:46 < svu> (or using setxkbmap)

Where the XKB configuration is grp:alts_toggle and ctrl:swapcaps

He also wondered if the bug occurs if you change your keyboard driver (evdev -> kbd or kbd -> evdev)

I switched my K/B from xkb -> evdev and the X server crashes on start: which is not so encouraging ;-)
Interestingly, running the keyboard capplet, and re-setting the layout options to default - fixed the problem for me magically - I'll keep poking at that.

I chopped the settings down to this much to reproduce the problem; going from the reset defaults (that work) to the broken-ness that does not:

--- /tmp/keyboard-resetdefaults.xml     2008-05-06 15:24:37.000000000 +0100
+++ /tmp/keyboard-stillbroken.xml       2008-05-06 15:40:12.000000000 +0100
@@ -71,7 +71,7 @@
       <key>general/defaultGroup</key>
       <schema_key>/schemas/desktop/gnome/peripherals/keyboard/general/defaultGroup</schema_key>
       <value>
-        <int>0</int>
+        <int>1</int>
       </value>
     </entry>
     <entry>
@@ -85,7 +85,7 @@
       <key>general/groupPerWindow</key>
       <schema_key>/schemas/desktop/gnome/peripherals/keyboard/general/groupPerWindow</schema_key>
       <value>
-        <bool>false</bool>
+        <bool>true</bool>
       </value>
     </entry>
     <entry>
@@ -175,6 +175,12 @@
       <schema_key>/schemas/desktop/gnome/peripherals/keyboard/kbd/layouts</schema_key>
       <value>
         <list type="string">
+            <value>
+              <string>us       basic</string>
+            </value>
+            <value>
+              <string>gb</string>
+            </value>
         </list>
       </value>
     </entry>
@@ -217,9 +223,6 @@
       </value>
     </entry>
     <entry>
-      <key>kbd.sysbackup/options</key>
-    </entry>
-    <entry>
       <key>layout/command_0</key>
       <value>
         <string>xmodmap /home/michael/.gkb_default.xmm</string>

With a little more re-booting action (such fun re-booting); I isolated it to the "groupPerWindow" key: this is the evil culprit - if I set it to true: life is bad, set to false - life is good: all else being equal.

The real question is: why !? :-)

with a little shell-scriptage, I swapped out gnome-session for a valgrind wrapper, and apparently this pops out:

==3382== Invalid read of size 1
==3382==    at 0x4720B5C: (within /usr/lib/libX11.so.6.2.0)
==3382==    by 0x47216A4: XkbSetMap (in /usr/lib/libX11.so.6.2.0)
==3382==    by 0x62BB871: XkbWriteToServer (in /usr/lib/libxkbfile.so.1.0.2)
==3382==    by 0x62A5116: (within /usr/lib/libxklavier.so.12.0.0)
==3382==    by 0x62A56B0: xkl_xkb_activate_config_rec (in /usr/lib/libxklavier.so.12.0.0)
==3382==    by 0x62A2141: xkl_config_rec_activate (in /usr/lib/libxklavier.so.12.0.0)
==3382==    by 0x62953CA: gkbd_keyboard_config_activate (in /usr/lib/libgnomekbd.so.2.0.0)
==3382==    by 0x62694F0: apply_xkb_settings (gsd-keyboard-xkb.c:158)
==3382==    by 0x62699E0: gsd_keyboard_xkb_load (gsd-keyboard-xkb.c:341)
==3382==    by 0x6268D95: gsd_keyboard_manager_start (gsd-keyboard-manager.c:421)
==3382==    by 0x62682E6: impl_activate (gsd-keyboard-plugin.c:78)
==3382==    by 0x804C43B: gnome_settings_plugin_activate (gnome-settings-plugin.c:52)
==3382==  Address 0x54230d8 is 0 bytes after a block of size 256 alloc'd
==3382==    at 0x4022E42: calloc (vg_replace_malloc.c:397)
==3382==    by 0x472BE9D: XkbAllocServerMap (in /usr/lib/libX11.so.6.2.0)
==3382==    by 0x62CD5FB: (within /usr/lib/libxkbfile.so.1.0.2)
==3382==    by 0x62CE142: XkmReadFile (in /usr/lib/libxkbfile.so.1.0.2)
==3382==    by 0x62A4E50: (within /usr/lib/libxklavier.so.12.0.0)
==3382==    by 0x62A56B0: xkl_xkb_activate_config_rec (in /usr/lib/libxklavier.so.12.0.0)
==3382==    by 0x62A2141: xkl_config_rec_activate (in /usr/lib/libxklavier.so.12.0.0)
==3382==    by 0x62953CA: gkbd_keyboard_config_activate (in /usr/lib/libgnomekbd.so.2.0.0)
==3382==    by 0x62694F0: apply_xkb_settings (gsd-keyboard-xkb.c:158)
==3382==    by 0x62699E0: gsd_keyboard_xkb_load (gsd-keyboard-xkb.c:341)
==3382==    by 0x6268D95: gsd_keyboard_manager_start (gsd-keyboard-manager.c:421)
==3382==    by 0x62682E6: impl_activate (gsd-keyboard-plugin.c:78)

Michael: FWIW, can't reproduce when playing with the "groupPerWindow" key. So there's probably something else going on, although I don't know what.

Stefan: can you take a look at the valgrind output in the last comment? Seems to indicate something is going wrong in some X libraries.

So how can I reproduce this issue? Could you provide a simple test case? Preferrably without any gnome libs and libklavier involved.

Stefan - well, it only appears to happen on my hardware ;-) [ I have a magic machine you see ]. Having said that valgrind has been kinder to me just now with it's traces [ and of course this may be a red herring ;-]:

==2572== Invalid read of size 1
==2572==    at 0x471EFBC: SendSetMap (XKBSetMap.c:331)
==2572==    by 0x471FB04: XkbSetMap (XKBSetMap.c:532)
==2572==    by 0x6293871: XkbWriteToServer (srvmisc.c:52)
==2572==    by 0x627DF9E: xkl_config_get_keyboard (xklavier_config_xkb.c:300)
==2572==    by 0x627E530: xkl_xkb_activate_config_rec (xklavier_config_xkb.c:471)
==2572==    by 0x627B0B1: xkl_config_rec_activate (xklavier_config.c:678)
==2572==    by 0x626E3CA: gkbd_keyboard_config_activate (gkbd-keyboard-config.c:713)
==2572==    by 0x62421D0: apply_xkb_settings (gsd-keyboard-xkb.c:158)
==2572==    by 0x6241A6B: gsd_keyboard_manager_start (gsd-keyboard-manager.c:421)
==2572==    by 0x624128E: impl_activate (gsd-keyboard-plugin.c:78)
==2572==    by 0x804C9CE: gnome_settings_plugin_info_activate (gnome-settings-plugin-info.c:506)
==2572==    by 0x804B3DD: maybe_activate_plugin (gnome-settings-manager.c:93)
==2572==  Address 0x541c078 is 0 bytes after a block of size 256 alloc'd
==2572==    at 0x4022E42: calloc (vg_replace_malloc.c:397)
==2572==    by 0x472A26D: XkbAllocServerMap (XKBMAlloc.c:170)
==2572==    by 0x62A55FB: ReadXkmSymbols (xkmread.c:647)
==2572==    by 0x62A6142: XkmReadFile (xkmread.c:1293)
==2572==    by 0x627DCE0: xkl_config_get_keyboard (xklavier_config_xkb.c:281)
==2572==    by 0x627E530: xkl_xkb_activate_config_rec (xklavier_config_xkb.c:471)
==2572==    by 0x627B0B1: xkl_config_rec_activate (xklavier_config.c:678)
==2572==    by 0x626E3CA: gkbd_keyboard_config_activate (gkbd-keyboard-config.c:713)
==2572==    by 0x62421D0: apply_xkb_settings (gsd-keyboard-xkb.c:158)
==2572==    by 0x6241A6B: gsd_keyboard_manager_start (gsd-keyboard-manager.c:421)
==2572==    by 0x624128E: impl_activate (gsd-keyboard-plugin.c:78)
==2572==    by 0x804C9CE: gnome_settings_plugin_info_activate (gnome-settings-plugin-info.c:506)

It seems that:

XKBSetMap.c (XkbSetMap):
    if (which&XkbExplicitComponentsMask) {
	req->firstKeyExplicit= xkb->min_key_code;
	req->nKeyExplicit = XkbNumKeys(xkb);
    }

And 'XkbNumKeys' looks like a '1 based' number; but then inside:

_XKbWriteKeyExplicit (inlined inside SendSetMap) we do:

    first= req->firstKeyExplicit;
    last= first+req->nKeyExplicit;
    i= XkbPaddedSize((req->totalKeyExplicit*2));
    BufAlloc(CARD8 *,wire,i);
**    for (i=first;i<=last;i++) {
	if (xkb->server->explicit[i]!=0) {
	    wire[0]= i;
	    wire[1]= xkb->server->explicit[i];
	    wire+= 2;
	}
    }

where i <= last (first + nKeyExplicit) looks like it assumes a '0 based' length (which would surely be unusual).

Of course, quite possibly not the problem as I say, but I'll patch it and see :-)

Hah, red herring it turns out: it would be nice to get the:

-last= first+req->nKeyExplicit;
+last= first+req->nKeyExplicit-1;

in there to match the method above in SendSetMap - that fixes the valgrind reported issue for me :-)

Thanks, Michael. I'll apply your patch.

BTW, in other locations it's done correctly. :-)

_XkbSizeKeyExplicit(...)
[...]
    first= req->firstKeyExplicit;
    last= first+req->nKeyExplicit-1;

    for (i=first,nFound=0;i<=last;i++) {
        if (xkb->server->explicit[i]!=0)
            nFound++;
    }
[...]

(In reply to comment #31 from Stefan Dirsch)
> Thanks, Michael. I'll apply your patch.

done. Fixed for Factory/X11:XOrg. Not sure if the fix will already be in Beta3.

Sadly the fix doesn't fix the underlying bug - my K/B is still broken beyond belief in the latest xorg - in fact, it's even worse :-)

I just upgraded to:

 rpm -q --changelog xorg-x11-server | head
* Mon May 05 2008 sndirsch@suse.de
- xorg-server-1.4-vnc-disable_render.diff
  * disabled RENDER support in Xvnc (bnc #385677)

* Mon Apr 21 2008 sndirsch@suse.de
- events.diff
  * eating up key events before going into the idle loop upon vt
  switch instead of after return (bnc #152522)

Any as well as dumping me with an (apparently) stuck alt-gr as I log in 1st time; as I log-in subsequently I can no longer switch desktops:

The arrows up/down/left/right are re-mapped, home/end/page-up/down are no longer sane keys (etc.) - in summary, bit hard to work ;-)

Interestingly, re-assigning the window movement keybindings the gnome accelerator config thing claims my arrows are like this:

left: henkan mode
up: Katakana
down: KP_Enter
right: Muhenkan

which is strange to say the least :-)

So I should better disable the patch again, right?

nah; the patch is fine & clearly correct - but IMHO unrelated to this problem.
I suspect the real problem in this case is me hacking the evdev driver to not crash on start :-) I'll remove that 'fix' and start again: ie. ignore #34 - it's provisionally bogus (for now)

Ok. Then I assign this bug better to you for now. :-)

sigh; so - reverting all to pristine, rpm --verified X stuff - I don't get #34 anymore (which is a blessing).

OTOH - I still get a complete broken keyboard behavior on 1st login:

Interestingly, this is completly reproducible if I do: init 3 / init 5 I get the same problem - which discards a race as being the cause I suppose [ which is encouraging ]. Apparently something related (somehow) to the auto-login goodness.

BTW, could it be that you're using gdm? It seems gdm doesn't make use of /etc/X11/xdm/Xstartup, so this stupid workaround 

  #
  # Fix keyboard layout (Bug #368673)
  #
  setxkbmap -print | xkbcomp - $DISPLAY

is apparently not applied for gdm users.

See also Bug #368673, comment #97.

Well - I retro-fitted the fixes from #368673 and even added an extra setxkbmap line to the gdm Xsession file and - no joy.

Same problem - so I guess, this is a different issue :-)

Ok. BTW, gdm is now reading Xstartup. Vincent changes this.

Is there any evidence that this is still a X.Org bug? I doesn't seem so.

the good news is that after upgrading this happens on x86_64 too - deep joy ;-)

Created attachment 216099 [details]
archive of data ...

In case it is at all useful - I attach the maximal libxklavier output with export XKL_DEBUG=10000
I've edited the valgrind fragments out of the logs replacing them with '===='
and binned most of the timestamps.
So - they are quite diff-able.
I also include the XKM & XKB maps generated libxklavier - the easy-to-read ones are the same, the others are slightly different

Unfortunately merging the supposedly broken map with xkbcomp broken :0.0 doesn't provoke the problem for me [ which is sad ].

I'm not clueful enough to know how to help more here.

(In reply to comment #42 from Stefan Dirsch)
> Ok. BTW, gdm is now reading Xstartup. Vincent changes this.

Yeah, this should fix the bug since, according to comment #9, "setxkbmap -print | xkbcomp - $DISPLAY" fixes it and this command will now be run by gdm (via Xstartup).

The new gdm package should hit factory in the next update (which should occur really soon now, I guess). Michael, will you be able to confirm it's fixed once you'll have upgraded to it?

So - the new gdm package will just not fix it - since I added the fix locally to see if it would & it didn't :-)

Also - check bug #368673# - it's now open again - and this (hack) didn't fix it there either :-) so - I guess they are questing for more & better hacks there now.

Created attachment 216373 [details]
xkbcomp dump on boot ie. broken

Created attachment 216374 [details]
good xkbcomp dump after re-login

encouragingly, at least for me running:

xkbcomp broken.xkb :0.0

reproduces the brokenness for me, and re-setting the good map makes it all happy again :-) so - that sounds at least like X might be doing what it is told at least later in the day. The question is - how do we get that broken setup & why only on auto-login ?

(In reply to comment #50 from Michael Meeks)
> encouragingly, at least for me running:
> 
> xkbcomp broken.xkb :0.0
> 
> reproduces the brokenness for me, and re-setting the good map makes it all
> happy again :-) so - that sounds at least like X might be doing what it is told
> at least later in the day.

Interesting: I still can't reproduce this way ;-)

ah - most likely you need your gconf in the same state as me too - to select the 2nd group. ie. when you read the diff broken->good between the two - a couple of things jump out:

-xkb_symbols "pc+gb+inet(microsoftpro)" {
+xkb_symbols "pc+us(basic)+inet(microsoftpro)+gb:2+ctrl(swapcaps)" {
 
-    name[group1]="United Kingdom";
+    name[group1]="USA";
+    name[group2]="United Kingdom";
 
     key  <ESC> {         [          Escape ] };
     key <AE01> {

First - that apparently the swap-caps didn't make it across in the first instance [ which is pretty odd ].

And second - there is no "group2" name in the broken xkbcomp output; so we see:

     key <AD02> {
-        type[group1]= "FOUR_LEVEL_ALPHABETIC",
-        symbols[Group1]= [               w,               W,         lstroke,         Lstroke ],
-        symbols[Group2]= [         lstroke,         Lstroke ]
+        type[group1]= "ALPHABETIC",
+        type[group2]= "FOUR_LEVEL_ALPHABETIC",
+        symbols[Group1]= [               w,               W ],
+        symbols[Group2]= [               w,               W,         lstroke,         Lstroke ]
     };

Apparently no 'type' for group1 - and in Group2 - we see that instead of 'w' or 'W' we have only 'lstroke' and 'Lstroke' - which are (seemingly) not what we want ;-) [cf. the 'working' version].

doesn't sound like a very generic problem to me.

So, I took Michael's gconf dump (attached on this bug) and applied it for a new user. I can now reproduce the issue with Michael's xkbcomp data from comment 50.

So, after playing around a bit, I decided to check by myself if this was happening in other distributions. I installed Ubuntu in VirtualBox and if I enable autologin and apply Michael's gconf dump, here we are, the bug is here. This is somewhat good (it's not openSUSE specific), but doesn't help that much...

More playing, use TimedLogin: after a timeout, gdm logs the user in.

 => if you just wait, the bug is here
 => if you type a letter and wait for the timeout, the bug does not happen
 => if you click on a button of the mouse and wait for the timeout, the bug does not happen
 => if you move the mouse without clicking and wait for the timeout, the bug is here

Crazy stuff. To me, it sounds like this (just a theory, of course):

 + when you run gdm, something is not initialized correctly
 + typing or clicking has a side effect of setting this something to some value
 + if it's not initialized and you then use xkb, things get broken

Just tried autologin with kdm3, and the problem occurs there too, so that's not a GDM-only issue.

Would be interesting to see if it's possible to reproduce the exact same issue with KDE (although I guess it might not be easy to set the same exact settings for the keyboard).

Will also try to play by patchin gnome-settings-daemon and/or libxklavier.

#57 may be of interest to KDE team

I played a lot with this at the hotel. Unfortunately, I hadn't downloaded the libX11 and the X server code, so I got slowed down.

I tried to play with kde3 instead of gnome to reproduce the bug, but without success. It could be because I didn't put the exact same settings as Michael's (although I tried to reproduce what I saw from gconf). It could also be because of the way KDE handles the XKB stuff (absolutely no idea how it's handled in KDE).

Adding a call in libxklavier to spawn "setxkbmap" on startup solves the issue.

Also, it seems that the issue appears because of the first call to XkbLockGroup (when a first window gets focused after g-s-d is started).

Still a lot of things to experiment to understand what's going on, though...

Oh, btw, if anybody else is reading the bug, my comment #19 was misinformed: it's normal to have state 0x2000, it just means that we're using the second xkb layout.

I discussed the issue with Daniel Stone, and upstreamed the bug: https://bugs.freedesktop.org/show_bug.cgi?id=16105

It seems Daniel knows part of the root cause, but it sounds worse than what he thought.

I've submitted an ugly workaround (running setxkbmap from gnome-settings-daemon after initializing the xkb stuff...). At least, it means our users won't be hit by this for 11.0.

Keeping the bug open to track the bug and find the right fix.

Lowering severity to Major because of the workaround, and removing gnome-showstopper

*** Bug 368673 has been marked as a duplicate of this bug. ***

Vincent - bad news: your workaround doesn't work for me ;-) at least I auto-login on my 64bit machine with the latest gnome-session including the fix (as of May 29) and my keyboard is still hosed ...

interestingly, init 3 / init 5 however didn't reproduce the problem with the fix present - but worked just fine (sigh): only the cold-boot caused the grief.

Michael: so, err, "fun" :-) If it works with init 3/init 5, then it's a good start and it probably means the workaround doesn't work because of some race. Maybe it's run before the X server does some stuff under heavy load (which is possible on boot). I'd love to ask you to reboot 10 times and see if it happens 10 times :-) 

Also note that it's not gnome-session that is important for the workaround, but gnome-settings-daemon. But I guess you have the latest version there too.

*** Bug 368673 has been marked as a duplicate of this bug. ***

Interestingly, this now works fine for me on the 32bit system I first saw this on and could repeat it reliably for; x86_64 is still reliably not working: most odd. Presumably some race condition provoked by >1 CPU in these 2 machines.

*** Bug 407860 has been marked as a duplicate of this bug. ***

*** Bug 412522 has been marked as a duplicate of this bug. ***

Does anyone have this problem in 11.1? I have the same problem in 11.1 with russian keyboard layout Bug #432627. 

I fix it for me by removing 103 and 104 lines from /etc/X11/xinit/xinirc.common, it is an old hack, that looks like not need anymore, because upstream fixed. 

The same issue and solution for me present in 11.0 with xorg 7.4 from buildservice.

Vitaliy: there's been no report of this on the GNOME side.

Vincent: but what you think about "stupid workaround" described above in comments #8-#10? It still needed in 11.1? In my opinion Bug #432627 caused by this workaround.

(In reply to comment #74 from Vitaliy Tomin)
> Vincent: but what you think about "stupid workaround" described above in
> comments #8-#10? It still needed in 11.1? In my opinion Bug #432627 caused by
> this workaround.

I honestly don't know. Note that I already commented on bug #432627 (comment #32).

(In reply to comment #62)
> I've submitted an ugly workaround (running setxkbmap from gnome-settings-daemon
> after initializing the xkb stuff...). At least, it means our users won't be hit
> by this for 11.0.
> 
> Keeping the bug open to track the bug and find the right fix.

The right fix is done: we have a newer X stack. Closing the bug.