This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 107733 - BIOS NUM state should be set and retained
BIOS NUM state should be set and retained
Status: CLOSED DUPLICATE of bug 115909
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-22 11:19 EDT by Felix Miata
Modified: 2014-03-16 22:39 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-30 16:36:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Felix Miata 2003-10-22 11:19:42 EDT
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 17:47:13 EDT
no improvement apparent in FC3 or FC4
Comment 2 Bill Nottingham 2005-09-30 16:36:38 EDT

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

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