Bug 467790 - Keyboard LED don't work properly
Keyboard LED don't work properly
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
13
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-20 17:32 EDT by Peter Gückel
Modified: 2018-04-11 08:06 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-16 12:28:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/Xorg.0.log (61.12 KB, text/plain)
2008-10-22 12:02 EDT, Peter Gückel
no flags Details
setxkbmap -print (267 bytes, text/plain)
2008-10-22 12:04 EDT, Peter Gückel
no flags Details
output of xkbcomp -xkb :0 out.xkb (46.56 KB, text/plain)
2008-10-22 12:06 EDT, Peter Gückel
no flags Details

  None (edit)
Description Peter Gückel 2008-10-20 17:32:06 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):
2.0.7-1

How reproducible:
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
  
Actual results:
The LEDs don't work properly

Expected results:
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.

Additional info:
Comment 1 Peter Gückel 2008-10-20 17:43:37 EDT
As a side note, I have not tested this in Gnome or XFCE.
Comment 2 Peter Gückel 2008-10-21 14:32:55 EDT
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.
Comment 3 Peter Hutterer 2008-10-21 21:47:01 EDT
(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
Comment 4 Peter Gückel 2008-10-22 12:00:57 EDT
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"
                  Exiting
Comment 5 Peter Gückel 2008-10-22 12:02:11 EDT
Created attachment 321171 [details]
/var/log/Xorg.0.log

/var/log/Xorg.0.log
Comment 6 Peter Gückel 2008-10-22 12:04:16 EDT
Created attachment 321172 [details]
setxkbmap -print

output of setxkbmap -print
Comment 7 Peter Gückel 2008-10-22 12:06:34 EDT
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.
Comment 8 Peter Hutterer 2008-10-22 21:50:34 EDT
(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.
Comment 9 Peter Gückel 2008-10-22 23:52:59 EDT
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).
Comment 10 Peter Hutterer 2008-10-23 00:07:29 EDT
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.
Comment 11 Peter Gückel 2008-10-23 00:22:19 EDT
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.
Comment 12 Bug Zapper 2008-11-25 23:02:51 EST
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 Peter Gückel 2009-02-13 18:54:18 EST
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.
Comment 14 Peter Gückel 2009-02-16 15:21:44 EST
[I changed platform to i686 because I use a 686-class processor and kernel-PAE.]
Comment 15 Peter Hutterer 2009-03-08 23:23:18 EDT
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.
Comment 16 Peter Gückel 2009-03-10 21:19:51 EDT
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.
Comment 17 Peter Gückel 2009-03-11 14:48:56 EDT
IT'S BACK!!!

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.
Comment 18 Peter Gückel 2009-03-11 14:52:12 EDT
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.
Comment 19 Peter Gückel 2009-03-12 19:37:36 EDT
News flash: I just connected a USB keyboard to the laptop and verified the problem there, too.
Comment 20 Peter Gückel 2009-04-10 12:40:32 EDT
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.
Comment 21 Peter Gückel 2009-04-14 12:23:47 EDT
I spoke too soon. It is not fixed with kernel-2.6.29.1-70.fc11.x86_64 and xorg-x11-drv-intel-2.6.99.902-3.fc11.x86_64 (if they have naything to do with it).
Comment 22 Bug Zapper 2009-06-09 05:49:28 EDT
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 23 Peter Gückel 2009-09-06 12:36:48 EDT
Update!

I have migrated to f12α and the problem still exists.
Comment 24 Peter Gückel 2009-09-19 14:41:18 EDT
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.
Comment 25 Peter Gückel 2009-10-26 13:41:04 EDT
Update! With kernel-2.6.31.5-96.fc12.x86_64, it is still broken.
Comment 26 Matěj Cepl 2009-11-05 12:12:30 EST
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.]
Comment 27 Peter Gückel 2009-11-05 23:28:08 EST
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).
Comment 28 Bug Zapper 2009-11-16 04:31:12 EST
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 29 Peter Hutterer 2010-01-14 01:04:33 EST
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.
Comment 30 Peter Gückel 2010-05-29 01:10:49 EDT
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.
Comment 31 Peter Gückel 2010-06-01 20:13:59 EDT
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.
Comment 32 Peter Gückel 2010-06-02 12:27:56 EDT
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.
Comment 33 Peter Gückel 2010-06-02 12:35:31 EDT
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.
Comment 34 Peter Gückel 2010-07-17 15:03:03 EDT
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.
Comment 35 Bug Zapper 2011-06-02 14:26:43 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 36 Peter Gückel 2011-06-16 12:28:38 EDT
end of life closed

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