This is literal repeat of what was filed originally as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183997 about 'xorg-x11-xkbdata-1.0.1-6' package from "development" set which is tracking closely the latest xorg versions. 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.
The current Fedora Core 5 xorg-x11-xkbdata package contains xkeyboard-config 0.8 with backward compatibility bits enabled.
I am not really sure it is an XKB configuration issue. I'd say it is rather X server problem with saving/restoring the indicator state. Were there any changes in the XKB code (especially related to indicators) between 6.8 and 6.9? Also, if you are using NOT xkeyboard-config but xkbdata (from original xorg) - does this problem exist?
> I am not really sure it is an XKB configuration issue. I am not sure either but, AFAIK, nobody is absolutely sure why this showed up. OTOH I know that with different versions of 'xorg-x11-xkbdata' things do work in different ways. You may want to check assorted comments at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183997 to find observations of various people.
What a mess... What I'd recommend is just try to play with pure X, layout 'us' and no environment (ok, twm is allowed). And then - increase the complexity (other layouts, powerful DEs etc). And see where it breaks...
This sounds very similar to https://bugs.freedesktop.org/show_bug.cgi?id=5635 . Anyways, problem reported in Gentoo as well[1], and I can confirm that xkeyboard-config causes the problem - old xkbdata is just fine. [1] http://bugs.gentoo.org/show_bug.cgi?id=125689
Yes, I'd say it is #5635 *** This bug has been marked as a duplicate of bug 5635 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.