2008/10/21 Eddy Petrișor <[EMAIL PROTECTED]>: > Hello, > > I have seen this behaviour, too for a long time now, but when I > initially looked for it, it was around the date of the report, so I > thought I'd be fixed. Now I see the problem is still there and the > release is getting closer. > > > I am still experiencing this behavour on two laptops; on both the ctrl > and caps keys are switched (on one I surely used the GNOME keyboard > thingie to setup the switch, while on the other I am unsure - not in > front of the machine).
On, laptop 1: I initially have the correct behaviour, but after disabling the caps-ctrl switch, the caps led remains linked to pressing ctrl; this was the output just after login: 0 [EMAIL PROTECTED] ~ $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "ro", "comma", "lv3:ralt_switch,ctrl:swapcaps,grp:shifts_toggle" - I logged in through the "new login/authentication" (sorry, I don't know the English equivalent since I am using GNOME in Romanian) menu from Applications->System Utilities from my wife's account - the keyboard settings was set both by a session command (reminiscent from the times the comma romanian variant wasn't accessible via the gnome-keyboard-preferences), still, that command just chose the comma variant, while - the gnome keyboard setting was responsible for the switch, and after I changed to default the layout toggle, and disabled the switch, the CAPS led was following the ctrl key presses This was the output after the last change: 0 [EMAIL PROTECTED] ~ $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "ro,ro,fr,us", ",std,,alt-intl", "lv3:ralt_switch" -------------------------- OK, I removed the command from thelist of commands to be ran at session login, and now I get by default: - CAPS led linked to cpas, although I have the caps-ctrl switch 0 [EMAIL PROTECTED] ~ $ xprop -root _XKB_RULES_NAMES _XK B_RULES_NAMES(STRING) = "xorg", "pc104", "ro,ro,fr,us", ",std,,alt-intl", "lv3:ralt_switch,ctrl:swapcaps" I disabled the switch and then I got (by coincidence the proper behaviour) and this xprop output: 0 [EMAIL PROTECTED] ~ $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "ro,ro,fr,us", ",std,,alt-intl", "lv3:ralt_switch" I even got into the aberant situation when I had the caps led on while CAPS was actually off via the following procedure: - gnome-keyboard-preferences -> layouts -> layout options... -> ctrl key position -> default - press ctrl - select swap ctrl and CapsLock - close the window I am suspecting the problem is in the gnome-keyboard-preferences applet, but how do I test? Is this enough? I tried to correct the issue in the command line via this command: 0 [EMAIL PROTECTED] ~ $ setxkbmap -layout ro,ro -variant ,std 0 [EMAIL PROTECTED] ~ $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "ro,ro", ",std", "lv3:ralt_switch,ctrl:swapcaps" but at this point the caps led linked its behaviour to CTRL, but in reverse mode (on when caps was off and vice-versa). I managed to correct the issue by doing the "ctrl key position" trick once more and then I issued: 0 [EMAIL PROTECTED] ~ $ setxkbmap -layout ro,ro,fr,us -variant ,std,,alt-intl -option 0 [EMAIL PROTECTED] ~ $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "ro,ro,fr,us", ",std,,alt-intl", "" 0 [EMAIL PROTECTED] ~ $ setxkbmap -layout ro,ro,fr,us -variant ,std,,alt-intl -option lv3:ralt_switch,ctrl:swapcaps 0 [EMAIL PROTECTED] ~ $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "ro,ro,fr,us", ",std,,alt-intl", "lv3:ralt_switch,ctrl:swapcaps" At this point everything worked as expected, so it seems that g-k-p is responsible for the aberant behaviour. Still I have a question, is this normal (the options double up): 0 [EMAIL PROTECTED] ~ $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "ro,ro,fr,us", ",std,,alt-intl", "lv3:ralt_switch,ctrl:swapcaps" 0 [EMAIL PROTECTED] ~ $ setxkbmap -layout ro,ro,fr,us -variant ,std,,alt-intl -option lv3:ralt_switch,ctrl:swapcaps 0 [EMAIL PROTECTED] ~ $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "ro,ro,fr,us", ",std,,alt-intl", "lv3:ralt_switch,ctrl:swapcaps,lv3:ralt_switch,ctrl:swapcaps" ------------------------------- So, as a conclusion: - changing "ctrl key position" via g-k-p behaviour can lead to caps led desyncs - using the command line to change that behaviour sometimes helps, but the resync can be obtained only via g-k-p - using the -option parameter of setxkbmap can lead to doubled up options I am NOT going to reassign this bug to g-k-p since I need someone to confirm my observations. -- Regards, EddyP ============================================= "Imagination is more important than knowledge" A.Einstein