Red Hat Bugzilla – Bug 428901
gnome-keyboard-properties becomes ineffective
Last modified: 2014-03-16 23:11:58 EDT
Description of problem:
In gnome-keyboard-properties, under 'Layout Options', there is:
Ctrl key position
[ ] Make CapsLock an additional Ctrl
This would appear to be analagous to the old 'Options "XkbOptions"
"ctrl:nocaps"' in xorg.conf. And if I set it, it behaves the same with one big
exception: the capslock LED still toggles whenever I hit the key, even though it
acts as 'Ctrl'. Setting the option in xorg.conf causes the LED to not trigger.
Version-Release number of selected component (if applicable):
Turning off, or not, LED is a truly minor thing in this update.
With control-center-2.21.5-1.fc9, and one of layout options in
gnome-keyboard-properties which locate "Ctrl" left of "A" key
(pick any of those) I see the following behaviours:
- hitting key marked "CapsLock" toggles capslock LED but that
key still function as Ctrl
- for reasons unclear the key in question stops working as ctrl
and pretends to be a "CapsLock" (no outward indicatons, LED
state appears totally independent)
- CapsLock state goes into an "upper case mode", with or without
updating LED, and it stays there regardless that options
displayed by gnome-keyboard-properties show otherwise or
that some other one was picked; no apparent ways to get
a lower key input from a keyboard any longer
- sometimes the state described in the previous point can be
cleared by doing "Reset to Defaults" in "Layout Options"
of gnome-keyboard-properties, followed by setting desired
options again, and sometimes not and one has to restart the
whole session to extricate himself from that bind.
A switch between situations described above may happen in the
middle of a session and apparently at random. Maybe there are
some triggers, like specific key sequences, but so far I failed
to notice anything of that sort.
With an update to control-center-2.21.90-7.fc9 the situation
become even worse. Regardless of chosen layout options, in particular
those concerning position and function of Ctrl key, after a login
one apparently gets a default layout does not matter what
"Layout Options" are showing up.
It looks like that to get a desired layout one needs to
"Reset to Defaults", set up options once again, and that lasts
through a session. With a new login that procedure has to be repeated.
A status of "Caps Lock" LED is just independent on what happens on
a keyboard. It is possible even to lock up a keybord in "upper case
only" state with this LED turned off (or on if so it happened).
adding to F9Blocker list. pretty icky sounding.
I've added Iran/Default to my keyboard layouts, but each time I restart my X,
changing the layout is impossible, evel with clicking on the keyboard indicator,
I sould remove that layout and readd it to be able to change the layout.
Sounds unlikely for a control-center problem. I would expect this to be an X or
The problem in comment #4 seems unrelated to the original bugreport, and is
likely to actually be a control-center issue. I see it too. Best to file
separate bug reports, rather than piling on here...
Upstream bug for the "configuration persistence" problem:
The configuration persistence problem is fixed in
For the original problem, this bug should be reassigned to the X side.
With the new gnome-settings-daemon, I see the layout applied correctly, and it
returns to the behavior described in comment #1. Reassigning.
It appears that currently although what LED shows is still pretty unrelated
to a state of a keyboard a chosen layout options are loaded and kept
(as opposed to what was described in comment #1 and comment #2).
OTOH a keyboard now is in a big mess, as detailed in bug 434669, so it is
hard to be sure.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
I notice that my keyboard settings (typing speed) are reset when I login to
GNOME, but as soon as I open some keyboard preferences they become effective.
should be fixed in rawhide with 906-5.
xorg-x11-server-1.5.0-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.