Red Hat Bugzilla – Bug 467790
Keyboard LED don't work properly
Last modified: 2018-04-11 08:06:16 EDT
Description of problem:
I have the NumLock on by default. Light is correct upon boot. When I press ScrollLock, NumLock extinguishes, although keypad still generates numbers, but ScrollLock does not alight (I don't know whether it truly stops scrolling text as it is supposed to). Pushing ScrollLock a second time alights ScrollLock (it has been pushed twice, so is ScrollLock now on or off, even though the light illumines), but NumLock remains extinguished. Pushing CapsLock reillumines NumLock and alights CapsLock. Pushing CapsLock a second time extinguishes CapsLock and NumLock remains alighted.
Version-Release number of selected component (if applicable):
Press the ScrollLock key.
Steps to Reproduce:
1. Press ScrollLock
2. Press ScrollLock again and test scrolling, keypad, etc
3. Press ScrollLock or CapsLock and test scrolling, keypad, etc
The LEDs don't work properly
One press of a keyshould alight the corresponding LED and enable the corresponding function without affecting other LEDs and their respective functions; and pressing a key a second time should extinguish the corresponding LED and disable the corresponding function without afftecting other LEDs and their corresponding functions.
As a side note, I have not tested this in Gnome or XFCE.
Update of 21.X.08 appears to have essentially fixed this. There are still some residual problems remaining:
1) the NumLock now does not alight upon boot, although keypad numbers are active (one has to press the button twice to have it illuminate).
2) the ScrollLock button now doesn't appear to do anything - it never lights up (I haven't tested whether it starts/stops scrolling, as it is supposed to).
Fixed in this update of this morning are the quirky CapsLock<-->ScrollLock interactions.
(In reply to comment #1)
> As a side note, I have not tested this in Gnome or XFCE.
wait, did you test it under X at all? if so, with what desktop environment?
Can you please provide your Xorg.log, the output of setxkbmap -print and the out.xkb file from xkbcomp -xkb :0 out.xkb
Yes, I tested it under X (actually, I never tested it in a command line run level). I use KDE. I have since updated to 2.0.7-2.
I have set KDE to turn on the NumLock and it is also turned on in the BIOS. As the system was booting, I noticed that the NumLock LED was on, but as soon as I got into KDE, it turned off, although numbers are activated on the keypad. When I press the NumLock key twice, numbers of the keypad are still activated, but now the LED alights correctly.
I have attached the files you desire, but am unable to give you out.xkb because of the following error:
Warning: Could not load keyboard geometry for :0
BadAlloc (insufficient resources for operation)
Resulting keymap file will not describe geometry
When I try the command as sudo su, I get:
No protocol specified
Error: Cannot open display ":0"
Created attachment 321171 [details]
Created attachment 321172 [details]
output of setxkbmap -print
Created attachment 321173 [details]
output of xkbcomp -xkb :0 out.xkb
Correction: those errors were generated, but the file was generated anyway! Here is the output of xkbcomp -xkb :0 out.xkb.
(In reply to comment #2)
> 1) the NumLock now does not alight upon boot, although keypad numbers are
> active (one has to press the button twice to have it illuminate).
i cannot reproduce this issue, though this may be related to my keyboard. on my laptop, NumLock actually doesn't trigger a numlock event in xev, and the numlock led seems to . the external usb keyboard works fine.
when you fire up xkbvleds after login (when numlock is still off), is the second led from the right on?
> 2) the ScrollLock button now doesn't appear to do anything - it never lights up
> (I haven't tested whether it starts/stops scrolling, as it is supposed to).
I can confirm that, though I haven't been able to figure out why yet.
No, the caplock LED is not on. They are all off after login (when numlock is still off and before I press numlock twice - and that, of course, has no effect on the capslock LED status).
Sorry, not the physical LED. xkbvleds is a little tool that displays the leds virtually. The second one from the right represents numlock and it should be on if you run it right after login before pressing numlock.
xkbvleds is part of xorg-x11-xkb-utils.
Okay. I had never heard of it. I just ran it: all the little bars are black. When I type the numlock twice, the second one from the right alights; when I type the capslock once, the first from the right alights; when I type scrolllock any number of times, nothing ever happens.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
I am using Fedora 11 alpha (rawhide).
The bug is still present.
It has evolved slightly...
When the computer is turned on, the NumLock LED is illuminated. As soo as I start to type something with an upper case letter, the NumLock LED is extinguished, although the number pad keys still output numbers. Depressing NumLock or CapsLock twice causes the NumLock LED to illumine and then it functions correctly for the remainder of the session.
[I changed platform to i686 because I use a 686-class processor and kernel-PAE.]
I just gave this a try again, with KDE's NumLock setting as "leave as default" and again as "NumLock on". Still can't reproduce it.
This is with today's rawhide on a x86_64 box.
Do you still see the bug? Have you tried creating a test user and reproducing the bug with the test user? It could be a stale configuration file that messes things up. Don't really know what else could cause it ATM.
I changed platform again (I just discovered that I have had a x86_64 system for almost 2 years without knowing it), so I reinstalled using the x86_64 repos. The problem has entirely disappeared.
I just update my new x86_64 system, got the new 218 kernel, so I decided to reboot to use it, and lo and behold, the first thing I noticed when I typed my password, containing a capital letter, is tht the NUM LOCK LED extinguished. I clicked the NUM LOCK key twice and now all is well. That is how this bug goes. One time a capitol letter is typeed, it extinguishes, although the number pad works properly, despite the extinguished LED, and clicking twice on the NUM LOCK key produces normal behaviour for the remainder of the session.
I also changed the bug to x86_64, as my desktop is using that. My laptop is i686 (PAE), but there is no separate keypad (those keys are reached via a special laptop function key) and there is no NUM LOCK LED, so I cannot verify it there.
News flash: I just connected a USB keyboard to the laptop and verified the problem there, too.
I think it is fixed, this Good Friday!!!
I just started the computer, I can't say I have been expressly paying attention these last days, and noticed that it works. I typed an upper case letter and the numlock led remained illuminated.
I spoke too soon. It is not fixed with kernel-126.96.36.199-70.fc11.x86_64 and xorg-x11-drv-intel-188.8.131.522-3.fc11.x86_64 (if they have naything to do with it).
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
I have migrated to f12α and the problem still exists.
Correcting the version, as I reported the bug and I am using f12α on both my computers.
I just noticed that I have typed a lot of upper case this session and the numlock led is still illuminated. Maybe it just got fixed in yeaterday's kernel (2.6.31-33.fc12.x86_64)? I will monitor the status.
Update! With kernel-184.108.40.206-96.fc12.x86_64, it is still broken.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).
Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.
If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
This bug still has not been fixed. The status is unchanged. I am using Fedora 12 (rawhide, with all the updates current to November 5, 2009 and I update daily).
The system still boots up with the num lock lit, then as soon as I type any upper case, ie., any character requiring shift, the led extinguishes, although numbers are still produced on the number pad. Pressing the num lock button twice causes the led to illuminate again and numbers are produced. After this initial time and having to press num lock twice, it works correctly for the remainder of the session, until next boot (I am not sure about loggin in and out, this bug has been unfixed for so long I don't know if I ever tried that).
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
I think the underlying cause here might be the same as for Bug 499961, which in itself has been reported upstream as Freedesktop bug 26035.
I am beginning to wonder whether the underlying problem was not KDE. Yesterday, I installed KDE-4.5 release candidate #1 from kde-redhat and this morning I suddenly noticed that the LEDs are working correctly! I will continue to monitor until KDE-4.5 final is released in July (I believe it is) and when it hits Fedora 13. I should add that I am now using Fedora 13.
I spoke too soon. Maybe it's selinux causing the problems? I don't know what I updated in the last couple of days -- basically everything that has come through the updates and updates-testing -- and the problem reappeared yesterday.
Now it works again! There were only about 2 or so updates-testing yesterday, so you should easily be able to determine which package it is.
Oops! I just thought of something. It likely never stopped working correctly since it finally began working in comment 30. I think it is working all the time now, but ceases to work only when I suspend to ram/resume. When I cold start, it works.
After continuous testing now for weeks, since my last posting, this now works as it should. The only problem that remains is that when coming back out of suspend-to-RAM, the old problem is back, exactly as it was initially. I have not ever gotten suspend-to-disk to work, so I cannot comment there. Starting the computer cleanly when it was turned off, this always works; it only fails when coming out of suspend.
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
end of life closed