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): xorg-x11-xkbdata-1.0.1-6
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 for tracking.
Thanks, tracking upstream at: https://bugs.freedesktop.org/show_bug.cgi?id=6162
Created attachment 125730 [details] information.png 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. Impact: Far worse for laptop users, becuase there is no obvious way of turning off Num-Lock and they are unable to type properly.
/desktop/gnome/peripherals/keyboard/general/disable_sysconfig_changed_warning 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 cases. 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.
IMPORTANT: 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 Lock issue.
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 from John. 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 relevance here). 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 a removal.
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 installation. 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 > installation. > > 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.