Bug 115909 - Do the right thing with the numlock state
Summary: Do the right thing with the numlock state
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-keyboard
Version: 21
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
Whiteboard: cleanup
: 107733 146529 (view as bug list)
Depends On:
Blocks: F10Target
TreeView+ depends on / blocked
Reported: 2004-02-16 23:20 UTC by Dax Kelson
Modified: 2015-04-30 18:33 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-04-30 18:33:46 UTC

Attachments (Terms of Use)

Description Dax Kelson 2004-02-16 23:20:30 UTC
Description of problem:

Currently Fedora/Redhat turns off the numlock on boot. It should
instead be configurable to do one of the following:

* Force off
* Force on
* Follow BIOS

SUSE LINUX supports this and defaults to "Follow BIOS".

To check the BIOS numlock setting, SUSE use the command hwinfo. I'm
wondering if that functionality could be added to kudzu? Both hwinfo
and kudzu are GPL.

The source can be obtained here:

Here is how it is pieced together:

## NumLock on? ("yes" or "no" or empty or "bios" for BIOS setting)

elif test "$KBD_NUMLOCK" = "bios"; then               
/usr/sbin/hwinfo --bios|grep -q 'Num Lock: on'

Sample output from 'hwinfo --bios'

01: None 00.0: 10105 BIOS
  [Created at bios.92]
  Unique ID: rdCR.lZF+r4EgHp4
  Hardware Class: bios
  BIOS Keyboard LED Status:
    Scroll Lock: off
    Num Lock: on
    Caps Lock: off
  Serial Port 0: 0x3f8
  Parallel Port 0: 0x378
  Base Memory: 639k
  PnP BIOS: @@@0000
  MP spec rev 1.4 info:
    OEM id: "DELL"
    Product id: "Dim 4600"
    1 CPUs (0 disabled)
  SMBIOS Version: 2.3
  BIOS Info:
    Vendor: "Dell Computer Corporation"
    Version: "A03"
    Date: "07/21/2003"
    Features: 001b00003c29de80 00000317
      PCI supported
      PnP supported
      APM supported
      BIOS flashable
      BIOS shadowing allowed
      ESCD supported
      CD boot supported
      Selectable boot supported
      EDD spec supported
      ACPI supported
      USB Legacy supported
      AGP supported
      LS-120 boot supported
      BIOS Boot Spec supported
  System Info:
    Manufacturer: "Dell Computer Corporation"
    Product: "Dimension 4600"
    Serial: "7L4XXXX"
    Wake-up: 0x06 (Power Switch)
  Board Info:
    Manufacturer: "Dell Computer Corp."
    Product: "02Y832"
    Serial: "..CNXXXXXXXXXXX."
  Chassis Info:
    Manufacturer: "Dell Computer Corporation"
    Type: 0x06 (Mini Tower)
  Processor Info:
    Processor Socket: "Microprocessor" (ZIF Socket)
    Processor Manufacturer: "Intel"
    Voltage: 1.1 V
    External Clock: 800
    Max. Speed: 3200
    Current Speed: 2800
    Status: 0x41 (Socket Populated, CPU Enabled)
  On Board Devices:
    Ethernet: "Intel Pro 100 VE Network Connection"
  On Board Devices:
    Sound: "AC'97 Audio Controller"
  OEM Strings:    www.dell.com
  Language Info:
    Languages: en|US|iso8859-1
    Current: en|US|iso8859-1
  Physical Memory Array:
    Max. Size: 4 GB (No Error Correction)
  Memory Device:
    Location: "CHANNEL A DIMM 0"
    Size: 256 MB
    Type: 64 bits, Syncronous SDRAM, DIMM
    Speed: 400 MHz
  Memory Device:
    Location: "CHANNEL B DIMM 0"
    Size: 256 MB
    Type: 64 bits, Syncronous SDRAM, DIMM
    Speed: 400 MHz
  Memory Device:
    Location: "CHANNEL A DIMM 1"
    Size: No Memory Installed
  Memory Device:
    Location: "CHANNEL B DIMM 1"
    Size: No Memory Installed
  Config Status: cfg=no, avail=yes, need=no

Comment 1 Alex Thomsen Leth 2004-02-17 00:12:50 UTC
this will be so good. less to configure when the fedora core is installed.

Comment 2 Scott Sloan 2004-02-17 01:20:41 UTC
I think this is a great idea and would make a great addition to FC2 test 2

Comment 3 Mike Chambers 2004-02-17 02:47:49 UTC
I agree think it should be configured to turn on or set options for it.

Comment 4 Jim Cornette 2004-02-17 03:15:42 UTC
Being left-handed and not worrying about the condition of the
numlocks. I would opt for the follow bios option.
Since setting on numlocks would interfere with many laptops. Turning
it on would be a bad idea. The user would get strange output when
using the keyboard.
It doesn't matter on adding the feature or not, to me. Except for the
idea of turning it on for laptop users.

Comment 5 Josiah Royse 2004-02-17 13:10:34 UTC
YES!  NumLock is a constant battle.

Comment 6 Fred New 2004-02-17 15:47:10 UTC
I also recommend adding a Num Lock setting to system-config-keyboard,
both gui and tui, so that this is easily and obviously configurable. 
This applet is currently only for setting the keyboard "language", but
is there any better place to configure the Num Lock setting:

Num Lock:
 o Off after boot
 o On after boot
 o Use BIOS setting

Comment 7 Gerald Neale 2004-02-20 22:31:45 UTC
Great idea.
Set to "On" by default is my choice.
It's easy enough to see that it is turned "on" on my keyboard because
a green light comes on. So the change should be shocking to nobody.
Mac OS X has  numlocks on by default and they do alot of testing on
desktop Unix users.

Comment 8 Aleksey Nogin 2004-03-10 08:33:24 UTC
I do not know - I hate numlock and I would have been pretty frustrated
if a new version of FC would have started insiting on having it on on
boot w/o me having a good idea of what's causing it. IMO it should
definitely be "use BIOS settings" by default (principle of least

Comment 9 Bill Nottingham 2005-01-29 04:06:41 UTC
*** Bug 146529 has been marked as a duplicate of this bug. ***

Comment 10 Stephen Warren 2005-03-19 23:51:54 UTC
I'd like to see this:

a) A root-settable config option for what happens at boot time, and hence what
happens at the login screen (possible settings: on, off, bios)

b) A user-settable config option for what happens after they login (at least for
X, although local TTY would be useful too) (possible settings: on, off, follow
system default)

And of course, when someone logs out, the setting from (a) should be restored.

Comment 11 Need Real Name 2005-04-14 14:38:31 UTC
See bug 91765 and bug 87946.

"Its one of those "religious" issues. Red Hat could decide to do different things
to the mainstream but for such a minor item it is not clear it is helpful. In
addition it gets more complicated once people start hotplugging USB keyboards.."

Comment 12 Fred New 2005-04-15 07:56:07 UTC
The package lock-keys-applet in Fedora Extras gives me what I need with regard to
this RFE.  It preserves the NumLock state between Gnome sessions.  I don't know
how it works in KDE and I don't know about USB keyboards.  Note that after
installing it you need to right-click on your gnome panel to add it.

Comment 13 Bill Nottingham 2005-09-30 20:36:53 UTC
*** Bug 107733 has been marked as a duplicate of this bug. ***

Comment 14 Felix Miata 2006-11-07 16:01:25 UTC
The nuisance of not following the BIOS NUM state is no small reason I usually
recommend SUSE over FC, as well as run SUSE on my 24/7 server. Standard desktop
10x keyboards ought to be hard wired for NUM always on.

# yum install lock-keys-applet
Installed: lock-keys-applet.i386 0:1.0-11.fc6
# lock-keys-applet
-bash: lock-keys-applet: command not found
# man lock-keys-applet
No manual entry for lock-keys-applet

Comment 15 Felix Miata 2006-11-07 16:25:33 UTC
bugzilla@redhat.com changed:

           What    |Removed                     |Added
           Severity|enhancement                 |normal
           Keywords|                            |FutureFeature

Bugzilla did the above, not me. All I did was add a comment, but it wouldn't
accept it until I removed the keyword, claiming that I didn't have authority to
add a keyword. It won't let me restore the severity either.

Comment 16 Need Real Name 2006-11-07 17:18:12 UTC
Numlock is on at boot for me since FC6.

You usually recommend SUSE, with all it's Yastness, over Fedora because of a
numlock default? Wow.

> # lock-keys-applet
rpm -ql lock-keys-applet

Comment 17 Felix Miata 2006-11-07 18:14:26 UTC
(In reply to comment #16)
> Numlock is on at boot for me since FC6.

Please tell how you do it.
> You usually recommend SUSE, with all it's Yastness, over Fedora because of a
> numlock default? Wow.

Because of several reasons that include turning num off all the time. This bug
is not an appropriate place to list them all.

> > # lock-keys-applet
> rpm -ql lock-keys-applet

Another reason is the deficiency in good community help, as evidenced by the
response in comment 16. I see nothing helpful in the output from rpm -ql
lock-keys-applet. Nothing in its doc tree contains information on how to use it,
and nothing in its output lives in any of the bin or sbin directories.

Note that I filed a request to remove this particular dysfunction over three
years ago in bug 107733, months before this bug was opened.

Comment 18 Need Real Name 2006-11-07 18:22:59 UTC
(In reply to comment #17)
> > Numlock is on at boot for me since FC6.
> Please tell how you do it.

I did nothing, it just started working.

> > rpm -ql lock-keys-applet
> Another reason is the deficiency in good community help

Hardly. The command I gave you lists all the files in the package.
If you don't want to go to Panel> Add, then you can look at the list of the
files in the package to see which binary to run.

Comment 19 Stephen Warren 2006-11-07 18:32:04 UTC
A Gnome (or anything else) panel applet is NOT the correct solution to this problem.

Panel applets don't run until you're actually logged in. To actually fix this
bug, the numlock state must be correct in all these locations:

* While the system is booting (e.g. if the system detect filesystem corruption
and drops you to a single-user login/shell), where panel applets cannot run.
* All VTs (text-mode consoles), where panel applets cannot run.
* At the X login screen, before panel applets run.

Comment 20 Felix Miata 2006-11-07 18:36:01 UTC
(In reply to comment #18)
> (In reply to comment #17)
> > > Numlock is on at boot for me since FC6.
> > Please tell how you do it.
> I did nothing, it just started working.

It didn't do that here, and I even rebooted to see if init would do it.
> > > rpm -ql lock-keys-applet
> > Another reason is the deficiency in good community help
> Hardly. The command I gave you lists all the files in the package.

I saw nothing helpful in that list. The README says nothing about how to use it.
The Gnome help files didn't seem that they could be of any use, since I don't
use Gnome, and am not concerned with NUM behavior in X, as I know how to make
KDE keep NUM on.

> If you don't want to go to Panel> Add, 

How does this work in runlevel 3?

>then you can look at the list of the
> files in the package to see which binary to run.

With no bin or sbin files in the list, there is nothing apparent about what to run.

Comment 21 Need Real Name 2006-11-07 18:41:55 UTC
Okay... I think we're talking at cross purposes here.

I'd like numlock to work consistently at boot onwards too, X or not.

However, you (from comment 20) included a bunch of comments talking about an
applet for a panel, so I'm trying to help you with that. It doesn't work in
runlevel 3, I never said it did, I was merely trying to help you get your applet

Comment 22 Dax Kelson 2006-11-07 22:31:40 UTC
The solution is laid out in comment 0. I've emailed the developer of
dmidecode/biosdecode to see if one of those programs could be modified to
extract the num lock status from the bios. The GPL'd SUSE app, hwinfo, does it
in src/hd/bios.c (around line 262).

With a BIOS num lock extracting dmidecode/biosdecode it would be fairly trivial
to get rc.sysinit (or some other bootup script) to use it like SUSE does (which
seems like an OK technique with no obvious problems).

Comment 23 Jean Delvare 2007-02-14 08:32:11 UTC
I've been thinking about it and my conclusion is that biosdecode isn't the right
place to implement this feature.

First of all, the BIOS settings are lost by the kernel as far as I can see. This
should be investigated. The most simple solution, which would cover all future
Linux distributions, would be to get the kernel to preserve (or restore) the Num
Lock state.

If this cannot be done for any reason (technical or political), then I think
that the right place to implement the "get the num lock status from BIOS"
feature is setleds itself. You're going to run it to enable the num lock anyway,
so rather than fetching the BIOS status from another tool, it's more efficient
to have setleds read it by itself.

So I suggest that code is added to setleds to retrieve and print the settings
from the BIOS (on systems which do support that) and possibly even a mechanism
to set the current state from the BIOS defaults in a single run.

Comment 24 Stephen Warren 2007-02-14 16:12:39 UTC
Putting functionality in setleds doesn't make sense to me.

I would image that setleds currently interacts just with APIs to control the
keyboard state, but has no code to interact with the BIOS/DMI/...

It makes much more sense to query the information using a BIOS utility which
already has BIOS interaction code.

It is, after all, the Unix way; each tool does its own job. After all, there's a
startup shell script to pass the information between the apps!

Comment 25 Jean Delvare 2007-02-14 16:23:06 UTC
What you call "BIOS interaction" is, in this case, as easy as opening /dev/mem
and reading one byte from it. Frankly, any program can do that.

Comment 26 Stephen Warren 2007-02-14 16:26:44 UTC
That's probably only true on an x86 PC. It's certainly not an assumption that
should be made globally.

Comment 27 Jean Delvare 2007-02-14 17:13:18 UTC
This is how hwinfo gets the information, and this is how I would implement it in
biosdecode if I did. I suspect we don't care about non-(x86 PC) here, as the
BIOS option to enable Num Lock at boot is an x86 PC option to start with.

Comment 28 Dax Kelson 2007-02-14 18:25:58 UTC
(In reply to comment #23)
> I've been thinking about it and my conclusion is that biosdecode isn't the right
> place to implement this feature.

I agree that the best solution would be for the kernel to preserve the
state of num lock. I'll post a message to l-k and see what happens.

However, is there any harm in biosdecode reporting on the setting in the

This could be useful even if:

a) The kernel gets modified
b) setleds get modified

Because (a) having a reporting tool would still be useful, and (b) having more
than one tool be able to report the same info is useful (many examples exist in
UNIX and Linux).

Another relevant point is that the SELinux (Debian/Fedora/RHEL/others) security
policy already allows biosdecode to open /dev/mem. If/when setleds reads
/dev/mem to get the settings, then the security policy will need to be patched
as well.

Comment 29 Jean Delvare 2007-02-18 16:50:54 UTC
Sorry but I'm not convinced by the reasons you give.

Having several tools to do the same basic thing doesn't fit into the Unix spirit
at all. That would be just like having another command that duplicates the
functionality of "ls" or "cp". Two tools means increased complexity, duplicated
maintenance workload. We deal with it when it happens, and it makes sense in
some cases, but in general we try to avoid it unless it's really necessary.

As for the upgrade path for the Linux distributions, it doesn't hold either.
Distributions which want the new feature (Num Lock state preserved on boot) will
need to update something anyway, be it the kernel, setleds, biosdecode and/or an
initialization script. If they need to update their security policies, this is
just one additional item, no big deal.

We better concentrate on what we think is the best final state, without
considering the upgrade path. This means: find where the feature is best
implemented, and implement it only there.

One thing that should be taken into account is that biosdecode is not normally
needed to run the system, and is usually included in a package that only some
developers install. For example, in Suse biosdecode is part of the pmtools
package, which isn't installed by default. On the other hand, setleds is part of
the kbd package, which is installed by default and needed for proper system
operation. I guess the situation is the same for other distributions. This is
one more reason to implement the feature in setleds rather than biosdecode for
the need you have, if it can't be fixed in the kernel itself.

Comment 30 Bug Zapper 2008-04-03 15:32:32 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 31 Trevor Cordes 2008-04-03 22:47:19 UTC
This "bug" still exists in F8.  Numlock is still always off by default with no
way to change the behaviour.

Comment 32 Felix Miata 2008-04-04 05:41:16 UTC
Actually there are ways. In /etc/rc.d/rc.local I put:

for tty in $INITTY; do
setleds -D +num < $tty

Some other distros make this easier for those not inclined to edit config files
in /etc.

Comment 33 Jon Stanley 2008-04-04 12:05:55 UTC
I'm going to change the component to s-c-k, since that's where the UI for this
feature would likely be implemented if it were to make it.  I'll also set this
as a Fedora 10 target - we're in bugfix only mode (no new features) for F9 right

Comment 34 Jon Stanley 2008-04-04 12:06:39 UTC
oops, forgot to set the FutureFeature keyword...sorry for the spam

Comment 36 Christopher Beland 2008-11-02 02:07:28 UTC
With Fedora 10 Snap 3+ (kernel-debug-, the numlock LED lights up after booting when I put the BIOS numlock setting to "on", and the LED if off after booting when the BIOS setting is off.  But this does not correlate to whether or not I can type numbers on the login screen using the number pad keys.  (See Bug 250236.)

Comment 37 Christopher Beland 2010-10-18 14:17:18 UTC
Confirming there are still problems in system-config-keyboard-1.3.1-2.fc14.x86_64.  I'm constantly having to turn Numlock back on after rebooting (and after starting to type expecting numbers and getting cursor movements instead).

Comment 38 Robert Mason 2015-02-25 10:34:12 UTC
I've just gone from CentOS 6 (where numlock worked fine) to a new install of Fedora 21. The numlock behaviour is very odd.

It is set to be on in the BIOS, and indeed, numlock is on after switching the computer on, but it turns off at some point while Fedora is booting up.

What's even stranger is it turns off while the computer is on. At first I thought it was just when the lock screen comes on that it forgets the numlock state, but I have just turned numlock on three times, and each time it went off again after a few minutes while I was in front of the computer.

I've also noticed that sometimes numlock IS on, but the light on the keyboard is off. So I can use the numpad, even though it says numlock is off. When this happens, the numlock key has to be pressed twice to get numlock AND the light on.

I think the default behaviour should be to follow the BIOS setting.

Comment 39 Trevor Cordes 2015-02-25 10:45:29 UTC
Good luck on this 2004 bug.  Though I am a bit surprised CentOS6 is any different from recent Fedora.

I've noticed steady improvement on Fedora numlock handling since 2004.  It's mostly right now.

I think I stopped seeing the magically-turns-off problem a few Fedoras ago, but I can't be positive.  Make sure you aren't just accidentally hitting numlock when you go to hit page-up like I always do.

The main issue I still see (but can't nail down) is when you hit numlock with a modifier key, or when scroll-lock is also on.  Sounds weird, but I often do shift or alt or ctl and page-up and I do it without looking and sometimes go a touch too far.  That can put the numlock into a weirdo state where it's actually backwards, just as you describe.  This should be easy to test.

However, "normal" "non-mistake" usage for me almost never results in wonky numlock anymore.  Like I said, they've been improving.

I think we'd have to provide them with concrete, simple, repeatable steps before anything new is going to get done on this.

PS: you might have better luck by telling BIOS to have numlock off and trying to configure Fedora to turn it on.  That might avoid the extra 1-2 state changes you are seeing.

Comment 40 Fred New 2015-02-25 12:01:54 UTC
I've been installing numlockx to turn "on NumLock after starting X", but now I see that something is turning NumLock off. For one thing, GDM turns it off when I hit the Shift (not NumLock) key while entering my password. Grr. Here I go to file another bug...

Comment 41 Robert Mason 2015-03-10 09:46:47 UTC
I've managed to narrow down the exact behaviour:

1. Computer boots, numlock and the light is on.
2. On the login screen, numlock and the light is on.
3. Type my password, which includes a capital letter. After pressing shift the numlock light goes off! But it is actually still on.
4. Press the numlock key twice to get it on with the light also on.
5. Now pressing shift doesn't affect it.

I do not think that pressing shift should cause the numlock light to turn off.

Comment 42 Fred New 2015-03-10 10:01:35 UTC
I believe that the numlock light turning off during login is bug 1083642, even though that bug is against RHEL 7.

Comment 43 Robert Mason 2015-03-10 10:27:46 UTC
Yes that looks like the same bug, thanks.

Comment 44 Christopher Beland 2015-04-30 18:33:46 UTC
There are four separate problems:
1. Pressing Shift etc. turns off light for non-US keyboards or after layout switch - Bug 1083642 (CentOS), Bug 1047151 for Fedora
2. Light wrongly stays on after logout - Bug 1217582
3. Numlock and/or light not in correct state on login screen and non-X text consoles given the BIOS setting.
4. Lack of UI to override the BIOS setting to affect login screen and non-X text consoles.

It sounds like after excluding (1) and (2), (3) might not be an issue anymore.  If anyone is still experiencing (3) or wants (4), please open a new bug and reference the discussion above.  I'm closing this one in the hope the BIOS problem is fixed, and it's gotten too confusing for anyone to come along and read it and do anything useful.

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