Could you please show the result of
gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd - when you have that option on and when it is reset at the session restart

Output when CapsLock is acting as CapsLock:

~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = []
 model = 
 options = [ctrl        ctrl:nocaps]
 overrideSettings = true

Output when CapsLock is acting as Ctrl:

~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = []
 model = 
 options = [ctrl        ctrl:nocaps]
 overrideSettings = true

On further investigation, I believe this may be a gdm bug, because it turns out that I was wrong and it is *not* true that the problem happens on every login -- it appears to happen exactly if the way I logged in was from starting gdm with its "Enable Automatic Login" option checked.  If I get to a gdm login screen in any other way (clicking "Logout", killing the X server, starting gdm with Automatic Login disabled) and then enter my username/password, then my CapsLock key works correctly in the resulting session; if I start gdm with Automatic Login enabled, then my CapsLock key does not.

Random idea: perhaps gdm (or initialization scripts, or some distro-specific mess-up -- I'm on Debian) is doing some of its own messing with the Xkb state of the X server, and this is racing with whatever session-specific stuff is supposed to read that gconf key.  So maybe it's getting set correctly, but then getting clobbered again.

It is somewhat misterious. Could you please do "xprop -root | grep XKB" in both cases as well?

Even better, I added a call to 'xprop -root -spy' to my system X startup scripts, so I could watch it throughout the session (I was worried about race conditions, so I wanted to monitor changes as well as end state).

Edited down log:

/etc/gdm/Xsession: Beginning session setup...
Could not open a connection to your authentication agent.
[...]
_XKB_RULES_NAMES(STRING) = "xorg", "pc104", "us", "", ""
[...]
_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc104", "us", "", ""
_XKB_RULES_NAMES(STRING) = "xorg", "pc104", "us", "", "ctrl:nocaps"
[...window manager starting up...]

So at first something seems to set it to the normal us layout, without the nocaps option, and then very early in the startup sequence (before metacity even gets going), it gets set again with the ctrl:nocaps option.  Then this is what the property remains set at.

So, when I have just started up from an auto-login gdm, my XKB settings are:
  _XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc104", "us", "", ""
  _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "us", "", "ctrl:nocaps"
and my capslock key does *not* act as a control key.

Then, if I open Keyboard Preferences -> Layout Options -> Ctrl key position and select "Default", the props change again:
  _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "us", "", ""
and then when I re-select "Make CapsLock an additional Ctrl.", they change back:
  _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "us", "", "ctrl:nocaps"

And this time it seems to take effect -- now my XKB settings are:
  _XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc104", "us", "", ""
  _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "us", "", "ctrl:nocaps"
and my capslock key *does* act as a control key.

Yes, this does mean that the _XKB_* properties are identical in the working and non-working cases.  I also see no evidence of a race condition -- just somehow the xkb settings are not taking effect?

Ah-hah -- I did find a difference between the working and non-working configuration.

Non-working configuration has XKB settings as above, and also has:

$ xmodmap
xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40),  Alt_R (0x71),  Meta_L (0x9c)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x7f),  Hyper_L (0x80)
mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x7c)

If I just run 'setxkbmap -v', then xmodmap changes:

~$ xmodmap
xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock      
control     Control_L (0x25),  Control_L (0x42),  Control_R (0x6d)
mod1        Alt_L (0x40),  Alt_R (0x71),  Meta_L (0x9c)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x7f),  Hyper_L (0x80)
mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x7c)

Non-solution: I noticed comments in the various session startup scripts about xmodmap and XKB "not playing well together", so I went through /etc/X11/Xsession* and /etc/gdm/* and commented out all mentions of xmodmap.  This had no effect.  (Also, I have no ~/.Xmodmap, and no mentions of xmodmap in my personal startup scripts, verified by running "grep -ri xmodmap ~/.*".)

Any other ideas?

> If I just run 'setxkbmap -v', then xmodmap changes:

What do you expect to get from that command?

(Sorry for late response, bugzilla was down when I first tried.)

> What do you expect to get from that command?

No idea; I have no conceptual model of XKB, and was hoping the empirical fact (running setxkmap with no arguments somehow fixes the problem) would lead to understanding on someone or the other's part, somehow.

Anyway, somehow, it seems, my keymap is getting *set*, but is not taking *effect*.  How can this be?  (Is this still the right place for this bug?  I can't tell if it has any connection to g-c-c anymore.  And if you don't know the answer, is there someone else who might?)

I'm afraid I've run into this bug, too. Unfortunately, I upgraded x.org and Gnome at once, so I cannot be sure that only Gnome is responsible for the bug.

In my case it goes as follows:
- I use no gdm; I start gnome-session from .xinitrc the old way.
- I use neither xmodmap nor special XKB options in my xorg.conf, relying solely on Gnome to set up the dual english-russian keyboard layout, which worked really well in 2.2.18. I got used to changing the layout with LCtrl+LShift and using the ScrollLock LED as the indicator.
- In 2.2.20, the layouts won't change initially. However, as soon as go to the keyboard setup and frob something XKB-related, e.g., change the keyboard type to and fro, layouts start switching and the LED indicator works.
- In order to rule out possible problems with my old 2.2.18 configs, I created a new user account and run Gnome under it. The problem still was there.

What is really strange is that the output from gconftool-2 or xprop doesn't change when layout switching starts to work:

[yar@dg ~]$ xprop -root | grep -i xkb
_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us", "", ""
_XKB_RULES_NAMES(STRING) = "xorg", "pc101", "us,ru", ",", "grp:lctrl_lshift_toggle,grp_led:scroll"
[yar@dg ~]$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = [us,ru]
 model = pc101
 options = [grp grp:lctrl_lshift_toggle,grp_led grp_led:scroll]
 overrideSettings = true
[yar@dg ~]$ echo могу печатать кириллицею
могу печатать кириллицею
[yar@dg ~]$ xprop -root | grep -i xkb
_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us", "", ""
_XKB_RULES_NAMES(STRING) = "xorg", "pc101", "us,ru", ",", "grp:lctrl_lshift_toggle,grp_led:scroll"
[yar@dg ~]$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = [us,ru]
 model = pc101
 options = [grp grp:lctrl_lshift_toggle,grp_led grp_led:scroll]
 overrideSettings = true

I'll be glad to provide any additional details or debug outputs as the problem starts really annoying me. :-)
Thanks!

Sorry, I messed Gnome versions. Of course, I meant 2.18 and 2.20.

That is really strange... Is it reproducable if you run gnome session from gdm?

No, the bug doesn't expose itself if I use gdm. But as soon as I stop gdm and return to using gnome-session, it's back.

This bug has manifested itself in a bunch of different ways on Ubuntu Hardy: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/173721. In that case, it seems to be related to existing users' settings when upgrading to 2.21.

As the original reporter, my symptoms have actually changed at some point -- maybe from an X upgrade?  Now, my CapsLock *does* automatically start working as an additional control key *but* every time I press it the CapsLock LED on my keyboard toggles, which slowly drives me insane.

Just like before, this only happens when I do a gdm "auto-login", and if I run "setxkbmap" with no arguments after starting up, the behavior reverts to what I'd expect -- my CapsLock becomes an ordinary Control key, and the LED goes out and stays out.

(In reply to comment #14)
> This bug has manifested itself in a bunch of different ways on Ubuntu Hardy:
> https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/173721. In
> that case, it seems to be related to existing users' settings when upgrading to
> 2.21.

We are probably looking at different issues here. Problems with g-c-c 2.21 and the new gnome-settings-daemon are most likely related (or the same as) bug 511771.

#16: Maayyybe... the only evidence in that Ubuntu bug log that implicates gnome-settings-daemon is a report that if you kill and restart it, that causes the keyboard settings to get reset correctly.  But that's not surprising when they say that touching any of the settings in g-c-p also gets things reset correctly, and in this bug just calling the "no-op" setxkbmap *also* resets things correctly.  (They haven't tried that, though, so we don't know if it would fix things for them or not.)  The bug hasn't been narrowed down at all.

...Surely g-s-d always does the same things when it's starting up, whether that's at login-time or when being restarted in the middle of the session?  How could those things work the second time, but not the first?  What's different between the two contexts?

(In reply to comment #16)
> We are probably looking at different issues here. Problems with g-c-c 2.21 and
> the new gnome-settings-daemon are most likely related (or the same as) bug
> 511771.

This does sound like exactly what I'm seeing.(In reply to comment #17)
> in this bug just calling the "no-op" setxkbmap *also* resets
> things correctly.  (They haven't tried that, though, so we don't know if it
> would fix things for them or not.)  The bug hasn't been narrowed down at all.

Just tried that, which did not help my particular case. Maybe I am seeing bug 511771 instead of this one?

I believe that I am also being bitten by this bug.

I'm using FreeBSD 7.0-STABLE and Gnome 2.22 from the freebsd ports tree, running as an amd64 system on a Mac Pro.  I believe that I had the same problem with Gnome 2.20 on this system but only ran it for a day and can't go back to check.  I see this behaviour with my account and with a newly created user account.

I also have my control and caps lock keys switched in my system console by setting my keymap to us.pc-ctrl in FreeBSD rc.conf file, which causes /etc/rc.d/syscons to use kbdcontrol to set that keymap.

I launch my X session from the command line using the system's startx command and a .xinitrc that simple exec's gnome-session.

If I use the System->Preferences->Keyboard->Layouts(tab)->Keyboard Layout Options->Ctrl key position radio buttons, I can select Swap Ctrl and CapsLock and the keys are effectively swapped and I'm happy (phew).

If I then exit the X session and run startx again I find that my settings aren't switched.  They'll switch again if I select Default and then Swap.... in the Keyboard Layout Options dialog.

Based on earlier comments on this bug i opened an xterm and ran 'setxkbmap -v'.  It says:

  (delicious)[12:42pm]etc>>setxkbmap -v
  Trying to build keymap using the following components:
  keycodes:   xfree86+aliases(qwerty)
  types:      complete
  compat:     complete
  symbols:    pc+us+ctrl(swapcaps)
  geometry:   pc(pc105)
  (delicious)[12:43pm]etc>>

and my control and capslock keys become swapped again (in other words they behave the way that I want them to).

I mentioned in my previous comment that I've also swapped control and capslock on my system console.  I just removed that change and rebooted the machine and am still having the issues described above.

If you're running 2.22, that might be bug 525440.

I grabbed the one-line change in bug 525440 and applied it to gnome-settings-daemon-2.22.0/plugins/keyboard/gsd-keyboard-manager.c but it didn't fix the problem.

The fix for bug 525440 is a call to apply_settings(), which only seems to be concerned with a fixed set of keyboard attributes (repeat rate, bell, etc...).

It doesn't seem to be concerned with optional settings.

I'm lost in a twisty passage full of daemons and don't quite understand who's responsible for what during startup.

Can anyone explain anything about which gnome component should be taking care of this?

After a bit of further digging I found bug 511771 which sounds similar.  It sounds like it was fixed by a call to gsd_keyboard_xkb_load in gsd_keyboard_manager_start .

Unfortunately this change doesn't seem to fix my problem.

FWIW, I cannot reproduce the behaviour with g-s-d trunk. CapsLock properly acts as Control after logging out and back in (after rebooting too). If anybody can come up with a way for me to reproduce it, I'll take a look.

I just checked out a copy of the g-s-d trunk.  It's not obvious to me how to build it in the context of my FreeBSD ports world.  autogen.sh complained about not having gnome-common from GNOME SVN.  I can probably drop various parts from the trunk tree into the unpacked 2.22 tarball and have a go at it, but when I diff the two trees I don't see any differences that seem relevant.  It seems like most of the changes involve either plugins or wrapping various things in gnome_settings_profile_{start,end} calls.

Jens, can you confirm that you tried to reproduce the behaviour by running gnome-session from a .xinitrc file via startx, and not by using gdm?

Thanks,

g.

I don't see any relevant changes, either, which is why I think it should work with 2.22 as well.

> Jens, can you confirm that you tried to reproduce the behaviour by running
> gnome-session from a .xinitrc file via startx, and not by using gdm?

No, I only tried with gdm (the original report specifically talked about gdm being involved in some way). I'll try with just startx, too, but I don't really see what kind of difference that would make.

What happens if you move the g-s-d binary away (so it cannot be auto-restarted by gnome-session), kill g-s-d, change the CapsLock option in Gconf, and then restart g-s-d manually (also use the --debug switch to see if anything goes wrong)? Does that work correctly, or does it show the same error?

I moved g-s-d to /usr/local/libexec/gnome-settings-daemon.GEORGE and confirmed that keyboard->layout->options settings was set to swap caps lock and control.

I killed the X server and killed all of my running gnome processes.

I started an X session and was greeted by a dialog box warning that g-s-d couldn't be started (no surprise).

The caps lock at this point was still a caps lock key.

I ran /usr/local/libexec/gnome-settings-daemon.GEORGE --debug and the caps lock key and control key were swapped.

So it seems to be doing the right thing.

Is there something else that might be running during startup that could be stepping on it?

Thanks!  

More random testing (sorry if I'm just thrashing, this is not necessarily consistent with the above).

Just for grins I logged in, observed that the control and capslock keys were not swapped, then killed g-s-d and let it restart.  The keys were still not swapped.

I moved g-s-d to g-s-d.GEORGE and killed the running g-s-d, keys remained unswapped.

I started g-s-d from an xterm w/ --debug and their were no errors and the keys remained unswapped.

If I set it to the default and then back to swap then the keys are swapped and I see no error messages.

Now I log out of the session and confirm that there's nothing gnomey left running, run startx and the keys are not swapped.  When I run g-s-d.GEORGE by hand with --debug then the keys are swapped.

Could something be goofy with the configuration/gconf database?

Thanks,
g.

What might be helpful is the output of
gconftool-2 --get /desktop/gnome/peripherals/keyboard/kbd/options
before each of those steps.

There's either a) something non-deterministic happening or b) I'm going crazy or c) there some effect-at-a-distance thing biting me/us.

I powered on the computer.

I mv'ed g-s-d to g-s-d.GEORGE

I started an X session via startx and checked the value of options.

 (delicious)[8:54am]~>>gconftool-2 --get /desktop/gnome/peripherals/keyboard/kbd/options
  [ctrl   ctrl:swapcaps]

and caps lock is still caps lock

After running g-s-d.GEORGE --debug

  (delicious)[DING!]~>>gconftool-2 --get /desktop/gnome/peripherals/keyboard/kbd/options
  [ctrl   ctrl:swapcaps]

and the caps lock keys are switched (in previous runs this didn't work...)

I'll attach the g-s-d --debug output and continue my comments.

Created attachment 108676 [details]
output from gconftool-2 and g-s-d --debug

Next I exited my X session and killed all of the gnome-y things left running.

Then I moved g-s-d.GEORGE back to g-s-d.

Then I started an x session via startx.

My caps lock and control key are not swapped.

the /.../kbd/options value is [ctrl   ctrl:swapcaps]

I killed g-s-d and let it restart, caps lock and control are still not swapped and the /.../kbd/options value is [ctrl   ctrl:swapcaps]

I repeated this a couple of times, same effect.

I moved g-s-d to g-s-d.GEORGE, killed the running g-s-d (generates a warning dialog box) and ran g-s-d.GEORGE by hand, and the caps lock and control keys are still not swapped.

I set system->preferences->layouts->layout options->Ctrl key position to default then back to swap and the keys finally switched.

One possible thought is that there is some conflict between /.../kbd/options and the fact that there is no /.../kbd.sysbackup/options value.  I tried copying the value from kbd/options to kbd.sysbackup/options using gconf and a) it didn't help and b) when I reinspected it via gconf its type had change from list of strings to integer.  I took a second whack at it, exiting the X session and killing off stragglers, then just copying the xml block from kbd/options into kbd/options.  That a) also didn't help and b) when I checked the value via gconftool-2 it had disappeared.

g-s-d does seem to do a dance using initial kbd values and its own data, but I don't understand what's happening there.

I added an 'Options "XkbOptions" "ctrl:swapcaps" line to my xorg.conf and there's now an options key in /.../keyboard/kbd.sysback.

That really looks rather odd. The only way I can think of right now to track this down is to run g-s-d in a gdb session and check in which way the code paths differ between startup (when the swapcaps option doesn't work) and toggling the option using the capplet (after which swapcaps does work).

I can't really help there since for me it does work on startup already,

Let me confirm that the issue is there for me, too. I use FreeBSD, too; it is unlikely yet possible that the issue is specific to the OS. In my case it manifests itself as follows.

My current environment:
- Gnome 2.22 (FWIW, the issue wasn't in 2.18, it appeared in 2.20 for the first time in my case);
- Gnome started via startx by invoking gnome-session from .xinitrc -- the issue won't show up if starting Gnome via gdm;
- no XKB customizations in xorg.conf.

I'd like to use Gnome's Keyboard settings to add the Russian layout, set the toggle combo to Shift-Alt, and make the ScrollLock LED the indicator.

When I just run startx and thus start Gnome, the keyboard settings don't seem to be applied: I cannot toggle the layout. But as soon as I go to the Keyboard settings window and make a token change, e.g., switch the keyborad type from 101-key to 102-key and back, I can toggle the layout and type Russian.

I also can reproduce the effect that starting gnome-settings-daemon manually, i.e., later into Gnome start-up, applies the settings OK immediately.

For test purposes I created a new user with clean configuration, i.e., with no left-overs from 2.18 or 2.20, and repeated my tests from under the user.  Nothing changed.

I hoped that the fix for bug #511771 would make my problem go away after I upgraded my Gnome to 2.22, but it hasn't.

Could gnome-settings-daemon run a bit too early during the Gnome start-up sequence and not get some key resource that is available a moment later?

It does indeed sound like we're having the same problem.  I'll drop a note to freebsd-gnome and ask if there's anything anyone can think of with gnome-session or hal or ??? that might cause FreeBSD to be acting this way.

Could you please insert debug print into gsd_keyboard_xkb_load and check whether it is being called at all?

> Could you please insert debug print into gsd_keyboard_xkb_load and check
> whether it is being called at all?

Yes, it is being called irrespective of whether g-s-d is stared automatically by gnome-session or manually later. Nevertheless the keyboard settings aren't applied in the former case.

(In reply to comment #36)
> It does indeed sound like we're having the same problem.  I'll drop a note to
> freebsd-gnome and ask if there's anything anyone can think of with
> gnome-session or hal or ??? that might cause FreeBSD to be acting this way.

FWIW I don't usually run hald, and I found it didn't matter really in this case.

I'll be away and off-line for the next fortnight. I'll be glad to do further debuging of this issue when I'm back, but I'll be unable to respond until then, sorry. Thanks!

That's really odd. Looks like a bug in xorg. In libxklavier, there are some test apps. If you try building libxklavier and playing with test_config (setting XKL_DEBUG=150 or more) - it could give some hint...

I just built up a fresh FreeBSD i386 box running -STABLE and a portsnap from yesterday.  It still suffers from the problem described above.

I can confirm Yar's observation that this problem does *not* happen if gdm starts things up.  It seems to be connected to using gnome-session.

I tried the test apps in libxklavier but couldn't make them tell me anything useful.  I'm not sure how they're relevant, since we've established that gnome *can* do the keyboard settings, making *any* change causes all of one's customizations to be installed.  It really seems to be the case that either they never get installed by gnome-session or they get overridden.

Thanks for everyone's thoughts on this!

It seems somehow I managed to reproduce the issue with startx. I'll keep you posted.

Well, I'm sorry to hear, yet very relieved, that you have the problem too... :)
 

You know, it really looks like a bug in xorg. xkbcomp is doing absolutely SAME things in both cases (startx and gdm), xorg gives no errors - but in startx case xkb is not configured. That's mistery... Just in case - what's your xorg version?

From xdpyinfo

X.Org version: 1.4.0

I've now seen the problem on an IBM Thinkpad T42p (building it up now from portsnap of two days ago) and an Apple Mac Pro w/ and NVidia graphics card and either their bluetooth wireless keyboards or their usb keyboard.

Another person already filed a bug against fd.o: https://bugs.freedesktop.org/show_bug.cgi?id=16105

Here's the corresponding bug in gentoo:
http://bugs.gentoo.org/show_bug.cgi?id=209962

Thanks for tracking this all down!

Seeing that the severity of this bug is "major" I wanted to make sure the notes on a related bug were communicated well.

http://bugzilla.gnome.org/show_bug.cgi?id=511771

I noted that the changes made to fix that bug were undone in later revisions. There could very well have been a different fix that I'm not aware of, but thought they might be connected.

If you look at the full change set, you'll see that the fix for bug 511771 has never been undone, and this issue is completely unrelated.

I've looked and I don't see what you're seeing. Here's what I see:

http://svn.gnome.org/viewvc/gnome-settings-daemon/trunk/plugins/keyboard/gsd-keyboard-manager.c?view=log

The fix for 511771 was to add "gsd_keyboard_xkb_load()". (Revision 117)

This line was taken out in revision 267 and has not been added back to the file in later revisions. Is there something I missed that countered the removal of this line?

Just trying to help.

You missed

http://svn.gnome.org/viewvc/gnome-settings-daemon/trunk/plugins/keyboard/gsd-keyboard-xkb.c?view=patch&r1=267&r2=266&pathrev=267

See the freedesktop bug Sergey pointed to.