There has been a similar question - but IMHO there has to be a simpler solution. If num-lock is on in the BIOS - why is it turned off during linux boot and/or KDE/Gnome/whatever startup?
1 Answers
Linux initializes most peripherals so that they'll be in a known state. This includes the keyboard: Linux's internal data about the keyboard had better match the LEDs, so what Linux does is to turn off the LEDs (as far as I recall, the CPU can't read the state of the LEDs on a PC keyboard) and declare all *Lock to be off.
I like to have NumLock on by default. For Linux text consoles, what I used to do¹ is to run
for t in /dev/tty[0-9]*; do setleds -D +num <$t; done
from a boot script (/etc/rc.local or /etc/init.d/50_local_setleds or wherever the distribution likes to put those).
Nowadays, at least on some distributions such as Debian, you can add LEDS=+num to /etc/console-tools/config (or /etc/kbd/config depending on which one you have).
The X window system has its own keyboard handling, so you need to deal with it separately. What I do is to switch caps lock permanently off (I don't have a Caps Lock key in my layout) and switch num lock permanently on (I don't have a Num Lock key in my layout, and the keypad keys send KP_1 and so on). If you want to retain the modifiers but make Num Lock default on, you can write a small program to call XKbLockModifiers to set the modifier inside X and XChangeKeyboardControl to set the physical LED.
¹ Used to, because I haven't bothered with text consoles in a while.
- 807,993
- 194
- 1,674
- 2,175
-
You mention consoles - was there not a kernel-option for numlock in old linux-kernels? 0.x or 1.y? Anyway - is there no Xconfig-option for numlock? – Nils Oct 26 '11 at 21:08
-
@Nils Mmmm maybe, I don't remember. I don't think there's anything for X, but I learned about keyboards in X before XKB existed, so I might be missing some of that newfangled stuff from the very late 20th century. – Gilles 'SO- stop being evil' Oct 26 '11 at 21:13
-
1I'll add a note that on Debian, the setting numlock after boot is done by the `kbd` package which creates an kbd init script. – carandraug Apr 24 '14 at 22:11
-
^ and I can assert no longer works, presumably due to the takeover by `systemd`. – underscore_d Oct 06 '15 at 22:40
-
The Operational System cannot know the state of a key? ARE YOU KIDDING? – Rodrigo Nov 30 '16 at 17:53
-
1@Rodrigo The operating system can know the state of a key. What it can't know, as far as I know, is the state of the LED — it can only remember whether it last turned the LED on or off, but that doesn't work across an operating system change (e.g. BIOS → bootloader → Linux). – Gilles 'SO- stop being evil' Nov 30 '16 at 18:05
-
What's the point in asking the state of the led, if you can get the state of the corresponding key? – Rodrigo Nov 30 '16 at 18:06
-
@Rodrigo The state of the key (pressed or not) doesn't give any information about the state of the LED (lit or not). – Gilles 'SO- stop being evil' Nov 30 '16 at 18:15
-
We are talking about NumLock. It's state is on/off, not pressed or not. – Rodrigo Nov 30 '16 at 18:21
-
@Rodrigo What do you mean by state of NumLock? There's a state in the keyboard, that's the LED which can be lit or unlit. There's a state in the OS, which determines how a keypad key press is interpreted; that state depends on the OS, and Linux has no way to know what the state in the bootloader was. (It could find out if it could read back the LED state from the keyboard, but that is not possible.) The translation from key code to motion-or-digit is done by the OS, not by the keyboard — this may be the source of your confusion. – Gilles 'SO- stop being evil' Nov 30 '16 at 18:29
-
The answers in http://stackoverflow.com/q/8427817/1086511 suggest you're wrong. – Rodrigo Nov 30 '16 at 18:50
-
1@Rodrigo That question deals with applications obtaining information from the operating system. The part you are arguing about is how the operating system would obtain the information. – Gilles 'SO- stop being evil' Nov 30 '16 at 18:52
-
I still don't understand you. If the application can get information from the OS, how could the OS don't have access to this information? – Rodrigo Nov 30 '16 at 21:11
-
@Rodrigo The OS keeps this information in memory. But when the OS starts, where would it get it from? The BIOS has the information in memory, the OS has this information in memory, but the BIOS doesn't tell the OS. So the BIOS num lock setting has no influence on the OS num lock setting. – Gilles 'SO- stop being evil' Nov 30 '16 at 21:20
-
Well, in my whole life I never had such a problem, so I used to think that older OSs could get this info from the BIOS. If an OS really can't, then it's another case of very illogical things happening where they shouldn't. Thanks for your patience. – Rodrigo Nov 30 '16 at 23:06
-
In 5 years (at least in KDE) we've come from all this to _Keyboard -> Num Lock on by Default_ – Coder Guy Jun 06 '17 at 17:13
-
Unfortunately, my question (https://unix.stackexchange.com/q/616579/439153) was marked and closed as a duplicate even though it was clear that it isn't. (It was concerned Xubuntu in particular and the answer from this ticket didn't work as I said in the comment to the possible duplicate suggestion. Unfortunately, that all went unanswered or heard.) Anyway, here is the answer that I selected there: Using `numlockx` to disable on each session start worked for me. Add it on Xfce Settings / Session and Startup / Application Autostart `numlockx off`. – Daniel Nov 19 '20 at 09:08