Bug 107733

Summary: BIOS NUM state should be set and retained
Product: [Fedora] Fedora Reporter: Felix Miata <mrmazda>
Component: distributionAssignee: Bill Nottingham <notting>
Status: CLOSED DUPLICATE QA Contact: Bill Nottingham <notting>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: mitr, rvokal
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-30 20:36:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Felix Miata 2003-10-22 15:19:42 UTC
Bug 87946 took the wrong approach to the wrong component, so that's why this
Fedora bug instead of reopening that RedHat bug.

Description of problem:
Most desktop i86 BIOS' have an option to have the NUM key preset to either the
ON state or the OFF state on boot. AFAIK, stock Linux kernels always flip NUM
off on startup when the BIOS state is ON. Then, even after boot is complete and
the user toggles NUM ON, when he switches to another console (but same
keyboard), the state reverts to off. This is confusing to users, and annoyingly
inefficient, often resulting in data loss. Compare to the behavior in the
various ubiquitous windoze versions, which maintain the BIOS NUM state on boot
until such time as that key is pressed.

What is needed is not the anachronistic *nix terminal behavior. A PC (normally)
has only has one keyboard attached to the motherboard's keyboard port, or to a
USB port, and only one user using it. The NUM state should not vary according to
whether the user switches among consoles. The state, however set, should be
maintained across sessions, and it should be initially set, and maintained, to
whatever value is in the BIOS, until such time as the user strikes the NUM key.

I'm not about to say how Fedora should accomplish this, but its absence is
enough to prevent me recommending Fedora (like RedHat) to anyone. Mandrake
installs a package NUMLOCK by default, which almost does the job right. In it,
all consoles and wm sessions get and have the state properly set and preserved.
The bug is that for some reason it is OFF in X login manager sessions. NAICT,
SuSE has a different approach, but the same absent ON state during X login
manger sessions. The initial state in SuSE is in the file/etc/sysconfig/keyboard
with e.g. 'KBD_NUMLOCK="bios", and like in Mandrake, it is preserved across
sessions.

Do we want to annoy migrators with an annoyance like this? Windoze doesn't do
it. It is no small annoyance to anyone used to using a tenkey machine, like a
data input operator or accountant, both of whom input large quantities of
numbers by touch typing. Do we not want these people using Fedora?

Nearly all desktop keyboards all have a separate cursor section and numpad
section. Let's default to optimum use of both of them.

How reproducible:
100%

Steps to Reproduce:
1.Set BIOS state ON
2.Boot
3.Strike 6345789 on the keypad
    
Actual results:
1.6345789 is not displayed

Expected results:
1.6345789 is displayed

Additional info:
http://home.sw.rr.com/linuxbits/NumLock.html
http://ftp.silug.org/pub/ltsp/setnumlock.tar.gz
http://caraldi.com/jbq/numlockx/
http://www.freshports.org/x11/numlockx/
http://dforce.sh.cvut.cz/~seli/en/numlockx/
http://packages.debian.org/unstable/x11/numlockx.html
http://www.gentoo.org/dyn/pkgs/x11-misc/numlockx.xml
http://slackware.tuxfamily.org/downloads/NumLockX/numlockx-1.0.tar.gz
http://rpmfind.net/linux/RPM/mandrake/9.0/x86_64/Mandrake/RPMS/numlock-2.0-8mdk.x86_64.html

Comment 1 Felix Miata 2005-09-29 21:47:13 UTC
no improvement apparent in FC3 or FC4

Comment 2 Bill Nottingham 2005-09-30 20:36:38 UTC

*** This bug has been marked as a duplicate of 115909 ***