Bug 115909

this will be so good. less to configure when the fedora core is installed.

I think this is a great idea and would make a great addition to FC2 test 2

I agree think it should be configured to turn on or set options for it.

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.

YES!  NumLock is a constant battle.

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

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.

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
surprize)...

*** Bug 146529 has been marked as a duplicate of this bug. ***

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.

See bug 91765 and bug 87946.

Quote:
"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.."

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.

*** Bug 107733 has been marked as a duplicate of this bug. ***

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
Complete!
# lock-keys-applet
-bash: lock-keys-applet: command not found
# man lock-keys-applet
No manual entry for lock-keys-applet

bugzilla 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.

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

(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.

(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.

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.

(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.

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
working.

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).

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.

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!

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.

That's probably only true on an x86 PC. It's certainly not an assumption that
should be made globally.

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.

(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
BIOS?

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.

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.

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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

This "bug" still exists in F8.  Numlock is still always off by default with no
way to change the behaviour.

Actually there are ways. In /etc/rc.d/rc.local I put:

INITTY=/dev/tty[1-8]
for tty in $INITTY; do
setleds -D +num < $tty
done

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

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
now.

oops, forgot to set the FutureFeature keyword...sorry for the spam

With Fedora 10 Snap 3+ (kernel-debug-2.6.27.4-68.fc10.x86_64), 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.)

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).

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.

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.

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...

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.

I believe that the numlock light turning off during login is bug 1083642, even though that bug is against RHEL 7.

Yes that looks like the same bug, thanks.

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.