Bug 214930 - Keyboard LED does not match NumLock state after boot, resume, or switch from VT
Keyboard LED does not match NumLock state after boot, resume, or switch from VT
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
Depends On:
  Show dependency treegraph
Reported: 2006-11-09 20:36 EST by Jack Spaar
Modified: 2008-01-15 09:39 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-15 09:39:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
xorg.conf (3.12 KB, text/plain)
2007-01-04 03:14 EST, Jack Spaar
no flags Details
Server log for attached xorg.conf (47.98 KB, text/plain)
2007-01-04 03:15 EST, Jack Spaar
no flags Details
Server log using no /etc/X11/xorg.conf (53.36 KB, text/plain)
2007-01-04 03:16 EST, Jack Spaar
no flags Details

  None (edit)
Description Jack Spaar 2006-11-09 20:36:24 EST
Description of problem:
In X, the keyboard LED is OFF when NumLock is ON (after a boot,
resume-from-hibernate, or switch from a virtual terminal).

Version-Release number of selected component (if applicable):

How reproducible: always

Steps to Reproduce:
1. Boot normally.
2. Log in to GDM session. 

1. Switch to a virtual terminal when NumLock is on.
2. Switch back to X.

1. Hibernate when NumLock is on.
2. Resume.

Actual results:
NumLock LED is off, but keypad functions as if NumLock is on.   (ABNORMAL)
Press NumLock again, LED stays off, keypad is non-numeric.      (NORMAL)
Press NumLock again, LED turns on, keypad is numeric.           (NORMAL

Expected results:
NumLock LED matches functional state of keypad when in X.

Additional info:
In a VT, the LED always matches the true keypad status.
In X, once the LED is properly sync'ed up (by hitting NumLock twice), it stays
in sync until resuming from hibernate or switching back from a VT.


This box was upgraded from FC5, and didn't display this behaviour before.
Comment 1 Matěj Cepl 2006-12-28 17:29:32 EST
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 2 Jack Spaar 2007-01-04 03:14:01 EST
Created attachment 144774 [details]

Option	    "XkbModel" "pc104"
Comment 3 Jack Spaar 2007-01-04 03:15:02 EST
Created attachment 144775 [details]
Server log for attached xorg.conf
Comment 4 Jack Spaar 2007-01-04 03:16:10 EST
Created attachment 144776 [details]
Server log using no /etc/X11/xorg.conf

Same results.
Comment 5 Jack Spaar 2007-01-04 03:28:46 EST
Keyboard is PS/2 connected, brand: BTC, model: 5123W, US style PC104-ish plus 3
power mgt. keys.

When NumLock LED is OFF while keys are numeric, pressing CapsLock key will turn
NumLock and CapsLock both ON.

Contrary to my original report, lately the NumLock LED is usually ON after GDM
login.  However the resume from suspend-to-disk and switch-from-VT problem still
occurs without fail.

Comment 6 Matěj Cepl 2007-12-10 04:24:37 EST
Fedora Core 6 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora 7, 8, or
Rawhide)? If this issue turns out to still be reproducible, please let us know
in this bug report. If after a month's time we have not heard back from you, we
will have to close this bug as CANTFIX.

Setting status to NEEDINFO, and awaiting information from the reporter.

[This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or
Gecko. If you see any other reason, why this bug shouldn't be closed, please,
comment on it here.]
Comment 7 Matěj Cepl 2008-01-15 09:39:55 EST
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional


{This is mass-closing of all obsolete bugs; if this bug was in your opinion
closed by mistake, please, reopen it with additional information; thanks a lot
and I am sorry for bothering you in such case.}

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