Red Hat Bugzilla – Bug 183997
xorg-x11-xkbdata - annoying ScrollLock LED behaviour
Last modified: 2007-11-30 17:11:26 EST
Description of problem:
With the current set of xkbdata logging in into a Gnome session (at least)
lights up ScrollLock LED. It turns out that NumLock key switches between
NumLock and ScrollLock LEDs. Going back to a text console will extinguish
ScrollLock LED and returning to a graphic screen will not make it to
light up - but only until NumLock was tapped twice. Then we are back to
the previous state. What happens with ScrollLock key does not have any
bearing on that LED.
All of the above holds unless "ScrollLock LED shows alternative group" box
is checked out in "Layout Options". Then this LED will stay dark regardless
of a status of keys picked up from "Group Shift/Lock behaviour" set.
Version-Release number of selected component (if applicable):
Please report this issue to the xkeyboard-config maintainers by filing
a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org
in the "xkbdesc" component.
Once you've filed your bug report upstream, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized upstream bug tracker, and will review any bug fixes that
become available for consideration in future updates.
Setting status to "NEEDINFO_REPORTER", awaiting X.Org bug URL
Thanks, tracking upstream at: https://bugs.freedesktop.org/show_bug.cgi?id=6162
Created attachment 125730 [details]
This behavior happens to me when I start my desktop from a FC4 GNOME profile,
but only after the GNOME session has run this dialog. This is true of Failsafe
GNOME as well, but not KDE. During GNOME startup I can repeatedly hit
Caps-Lock and it has no effect on Num-Lock, but Num-Lock happens as soon as
this dialog pops up.
Given the above, this might be a GNOME specific issue.
Far worse for laptop users, becuase there is no obvious way of turning off
Num-Lock and they are unable to type properly.
setting this gconf key only hides the dialog during GNOME startup, but the
problem does not go away.
Tested with a supplemental USB keyboard plugged into my laptop. Caps-Lock has
the same bad behavior as above. The extended keyboard Num-Lock key however is
successful in disabling Num-Lock.
GNOME > Preferences > Keyboard > Layout Options > Use keyboard LED to show
alternative groups > NumLock LED shows alternative group
If I enable this option, then it seems to fix this bad behavior. Even if I turn
it off again, it remains fixed. How do I undo this change to my profile in
order to reproduce the original problem?
I suspect that some of these options are "undefined" in existing GNOME user
profiles, and somewhere around February 24th the system changed and broke these
fedora-devel-list has a complaint that the "compose" key suddenly changed,
perhaps this a similar problem. We really should look into all possible impact
scenarios of this issue or we will have unhappy FC4 upgrade users and many
strange and difficult to understand bug reports against wrong components when
FC5 is released.
If you can reproduce this problem, please follow this procedure before you try
the workaround described above.
gconftool-2 -R /desktop/gnome/peripherals/keyboard > keyboard-backup.txt
Then please attach that file to this report. We need data in order to reproduce
this and other potential similar problems.
Created attachment 125744 [details]
requested gconftool-2 -R /desktop/gnome/peripherals/keyboard output
Note that it contains various cruft from upgrading multiple times before. I'm
seeing the Scroll Lock issue after the upgrade. I've changed features since
the upgrade, but haven't done the fix suggested in the comment for the Scroll
After doing that, I tried the work around. Changing "NumLock LED shows
alternative group" had no effect (other than making the NumLock LED not light
up). Changing "ScrollLock LED shows alternative group" made the ScrollLock LED
turn off (since I wasn't in an alternative group), but it came back on as soon
as the option was turned off. The original "ScrollLock LED is the reverse of
the NumLock LED" returned.
Try turning it on and off. Is the behavior the same as before you toggled it?
Yes, behavior is exactly the same as before I toggled the option. (Assume you
mean the ScrollLock option, rather than, as you wrote, the NumLock option.)
Slight difference in my issue than what seems to be described-- Either the
NumLock OR CapsLock turning on will make the ScrollLock LED go off.
(In reply to comment #12)
> Yes, behavior is exactly the same as before I toggled the option. (Assume you
> mean the ScrollLock option, rather than, as you wrote, the NumLock option.)
It seems to me that the problem Warren describes is somewaht different to that
I'm seeing exactly the same symptoms as John.
> Slight difference in my issue than what seems to be described-- Either the
> NumLock OR CapsLock turning on will make the ScrollLock LED go off.
This, too. Microsoft Natural Keyboard connected via USB. Happens on a fresh
account, too. Toggling the GNOME options as described in #7 doesn't help.
Created attachment 125746 [details]
another 'gconftool-2 -R /desktop/gnome/peripherals/keyboard' output
AFAICS what I am seeing, and what I reported originally, is something
like described by John and not by Warren. Changing ""ScrollLock LED
shows alternative group" toggles that off and on. But this is on
a desktop machine and not on a laptot (and x86_64 if that has any
What brought into gconftool-2 output this "ar azerty" stuff I really
do not know. It was not something I added there and I was never using
such layout. It does not show at this moment in "Layouts" tab of "Keyboard
Preferences" window. It did at some moment in the past but I asked for
Created attachment 125749 [details]
my gconf2 keyboard
Whatever changed in xorg-x11-xkbdata-1.0.1-7 I do not see ScrollLock LED
to light up; as a matter of fact in any circumstances and does not matter
which keys are pushed and that includes ScrollLock itself. At the first
glance other recent updates should be immaterial.
I am not sure how this affects laptop keyboards. I do not have such test
So whos problems is that really and what should be closed? Is this truly
a freedesktop.org baby?
Happening here with KDE, too. Behaviour is actually "scroll lock led lights up
when X starts, and goes out if either num lock or caps lock are on (or both)".
Could be a kernel issue, since I *didn't* see it *after* updating to recent
xorg + xkbdata packages but *before* booting into a recent kernel.
Hmm, scratch that, "xkbvleds" shows the same behaviour as the physical LEDs.
problem *almost* solved with xorg-x11-xkbdata-1.0.1-7, but now the scrollkey
never lights up.
(In reply to comment #16)
> Whatever changed in xorg-x11-xkbdata-1.0.1-7 I do not see ScrollLock LED
> to light up; as a matter of fact in any circumstances and does not matter
> which keys are pushed and that includes ScrollLock itself. At the first
> glance other recent updates should be immaterial.
xorg-x11-xkbdata-1.0.1-7 contained an update from
xkeyboard-config 0.7 to version 0.8
> I am not sure how this affects laptop keyboards. I do not have such test
> So whos problems is that really and what should be closed? Is this truly
> a freedesktop.org baby?
That's not clear yet. I assume it's an xkeyboard-config bug, but rstrode
has suggested in IRC that it could be a GNOME bug perhaps. Bill Crawford
above claims to have the problem in comment #17 which would make it seem the
problem is not limited to GNOME, but more generic. I don't know if our
KDE setup causes any GNOME stuff to run in the background or not though.
I'm still assuming this is an xkeyboard-config problem for now in light
of new data pointing to something else.
Moving to FC5Update, FC6Target trackers as FC5 is baked.
I've seen this strange scroll-lock behaviour todat too, after doing a full
update 2 rawhide its completly gone. Notice I do not and have nver used the leds
to show alternative keyb groups.