[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#459371: caps led toggles when I have ctrl and caps switched



2008/10/21 Eddy Petrișor <eddy.petrisor@gmail.com>:
> 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 eddy@bounty ~ $ 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 eddy@bounty ~ $ 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 eddy@bounty ~ $ 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 eddy@bounty ~ $ 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 eddy@bounty ~ $ setxkbmap -layout ro,ro -variant ,std
0 eddy@bounty ~ $ 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 eddy@bounty ~ $ setxkbmap -layout ro,ro,fr,us -variant ,std,,alt-intl -option
0 eddy@bounty ~ $ xprop -root _XKB_RULES_NAMES
_XKB_RULES_NAMES(STRING) = "xorg", "pc104", "ro,ro,fr,us", ",std,,alt-intl", ""
0 eddy@bounty ~ $ setxkbmap -layout ro,ro,fr,us -variant
,std,,alt-intl -option lv3:ralt_switch,ctrl:swapcaps
0 eddy@bounty ~ $ 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 eddy@bounty ~ $ xprop -root _XKB_RULES_NAMES
_XKB_RULES_NAMES(STRING) = "xorg", "pc104", "ro,ro,fr,us",
",std,,alt-intl", "lv3:ralt_switch,ctrl:swapcaps"
0 eddy@bounty ~ $ setxkbmap -layout ro,ro,fr,us -variant
,std,,alt-intl -option lv3:ralt_switch,ctrl:swapcaps
0 eddy@bounty ~ $ 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

Reply to: