Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Do the right thing with the numlock state|
|Product:||[Fedora] Fedora||Reporter:||Dax Kelson <dkelson>|
|Component:||system-config-keyboard||Assignee:||Lubomir Rintel <lkundrak>|
|Status:||CLOSED DEFERRED||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||21||CC:||aleksey, beland, collura, fred.new2911, jason, jdelvare, jonstanley, jroyse, link, mitr, mrmazda, nullpost-redhat, swarren, trevor, triage|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-04-30 14:33:46 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Dax Kelson 2004-02-16 18:20:30 EST
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: ftp://ftp.suse.com/pub/suse/i386/9.0/suse/src/hwinfo-7.30-32.src.rpm Here is how it is pieced together: /etc/sysconfig/keyboard ::::::::::: ## NumLock on? ("yes" or "no" or empty or "bios" for BIOS setting) KBD_NUMLOCK="bios" ::::::::::: /etc/init.d/kbd ::::::::::: 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-16 19:12:50 EST
this will be so good. less to configure when the fedora core is installed.
Comment 2 Scott Sloan 2004-02-16 20:20:41 EST
I think this is a great idea and would make a great addition to FC2 test 2
Comment 3 Mike Chambers 2004-02-16 21:47:49 EST
I agree think it should be configured to turn on or set options for it.
Comment 4 Jim Cornette 2004-02-16 22:15:42 EST
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 08:10:34 EST
YES! NumLock is a constant battle.
Comment 6 Fred New 2004-02-17 10:47:10 EST
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 17:31:45 EST
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 03:33:24 EST
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)...
Comment 9 Bill Nottingham 2005-01-28 23:06:41 EST
*** Bug 146529 has been marked as a duplicate of this bug. ***
Comment 10 Stephen Warren 2005-03-19 18:51:54 EST
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 10:38:31 EDT
Comment 12 Fred New 2005-04-15 03:56:07 EDT
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 16:36:53 EDT
*** Bug 107733 has been marked as a duplicate of this bug. ***
Comment 14 Felix Miata 2006-11-07 11:01:25 EST
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
Comment 15 Felix Miata 2006-11-07 11:25:33 EST
firstname.lastname@example.org 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 12:18:12 EST
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 13:14:26 EST
(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 13:22:59 EST
(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 13:32:04 EST
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 13:36:01 EST
(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 13:41:55 EST
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.
Comment 22 Dax Kelson 2006-11-07 17:31:40 EST
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 03:32:11 EST
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 11:12:39 EST
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 11:23:06 EST
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 11:26:44 EST
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 12:13:18 EST
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 13:25:58 EST
(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.
Comment 29 Jean Delvare 2007-02-18 11:50:54 EST
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 11:32:32 EDT
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.
Comment 31 Trevor Cordes 2008-04-03 18:47:19 EDT
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 01:41:16 EDT
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.
Comment 33 Jon Stanley 2008-04-04 08:05:55 EDT
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.
Comment 34 Jon Stanley 2008-04-04 08:06:39 EDT
oops, forgot to set the FutureFeature keyword...sorry for the spam
Comment 36 Christopher Beland 2008-11-01 22:07:28 EDT
With Fedora 10 Snap 3+ (kernel-debug-220.127.116.11-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.)
Comment 37 Christopher Beland 2010-10-18 10:17:18 EDT
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 05:34:12 EST
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 05:45:29 EST
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 07:01:54 EST
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 05:46:47 EDT
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 06:01:35 EDT
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 06:27:46 EDT
Yes that looks like the same bug, thanks.
Comment 44 Christopher Beland 2015-04-30 14:33:46 EDT
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.