Bug 428901

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.

Any idea?

Best,
adrin.

Sounds unlikely for a control-center problem. I would expect this to be an X or
xkb-config problem.

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:
http://bugzilla.gnome.org/show_bug.cgi?id=511771

The configuration persistence problem is fixed in
gnome-settings-daemon-2.21.90.1-3.fc9. 

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.