Bug 428901 - gnome-keyboard-properties becomes ineffective
gnome-keyboard-properties becomes ineffective
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-keyboard (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Peter Hutterer
Depends On:
  Show dependency treegraph
Reported: 2008-01-15 17:33 EST by Bill Nottingham
Modified: 2014-03-16 23:11 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-09-16 19:27:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 509804 None None None Never

  None (edit)
Description Bill Nottingham 2008-01-15 17:33:13 EST
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):

Comment 1 Michal Jaegermann 2008-01-19 16:37:55 EST
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.
Comment 2 Michal Jaegermann 2008-02-05 15:22:58 EST
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).
Comment 3 Ray Strode [halfline] 2008-02-06 11:40:48 EST
adding to F9Blocker list.  pretty icky sounding.
Comment 4 Adrin Jalali 2008-02-07 10:56:08 EST
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?

Comment 5 Matthias Clasen 2008-02-07 11:46:20 EST
Sounds unlikely for a control-center problem. I would expect this to be an X or
xkb-config problem.
Comment 6 Matthias Clasen 2008-02-07 11:52:51 EST
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...
Comment 7 Matthias Clasen 2008-02-07 12:04:39 EST
Upstream bug for the "configuration persistence" problem:
Comment 8 Matthias Clasen 2008-02-07 23:19:07 EST
The configuration persistence problem is fixed in

For the original problem, this bug should be reassigned to the X side.
Comment 9 Bill Nottingham 2008-02-08 10:41:28 EST
With the new gnome-settings-daemon, I see the layout applied correctly, and it
returns to the behavior described in comment #1. Reassigning.
Comment 10 Michal Jaegermann 2008-02-24 16:28:43 EST
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.
Comment 11 Bug Zapper 2008-05-14 00:47:05 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 12 Felipe Contreras 2008-05-14 17:18:42 EDT
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.
Comment 13 Peter Hutterer 2008-08-06 02:40:48 EDT
should be fixed in rawhide with 906-5.
Comment 14 Fedora Update System 2008-09-16 19:27:00 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.