Situation: I have a script watching over NumLock status, well not really watching, but turning it On every 1 second. The script is running in the background.

Reasoning: I often accidentally turn off NumLock. And I have no indicator of NumLock status on the keyboard.

OS, DE, DM, WM, xmodmap:

Operating System:

$ lsb_release -a

No LSB modules are available.
Distributor ID: LinuxMint
Description:    Linux Mint 18 Sarah
Release:    18
Codename:   sarah

Desktop Environment:



Display Manager:

cat /etc/X11/default-display-manager


Window Manager:

wmctrl -m | head -n 1

Name: Mutter (Muffin)


xmodmap -pm

xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

My original Bash script follows:


while true

  numlockx on

  sleep 1s


As you can see, the script does not care about current status of NumLock. It just keeps turning it on.

Goal: I would like to make the script at least somewhat CPU efficient.

Question: What is the most CPU efficient way to ensure that NumLock is On in Linux (Mint 18)?


No, it is not efficient. The problem is, the cost of querying the NumLock state is the same as the cost of setting the NumLock state. So, you would just double the load if you try to query state before setting it.

You could make it a little better by writing compiled C code, as you would avoid fork / exec and interpreting costs, but it would still remain a horrible hack.

What you could do instead, is to set the NumLock on, and then disable NumLock key (or even ignore it's state if all you want is numeric keypad always numeric).

See this SuperUser post for details how to do that with xmodmap(1).


We have found the solution on Code Review:

setxkbmap -option numpad:mac

So far, I don't see any crippling of my key mappings.


The most CPU efficient way is to just disable NumLock using xmodmap, then you don't need to poll the NumLock status at all. In other word, CPU time spent is zero. This can be done with

xmodmap -e "remove mod2 = Num_Lock"

and if you want to use it again, turn it on with

xmodmap -e "add mod2 = Num_Lock"

Alternatively, make an ~/.Xmodmap file with a similar line, and make sure your X startup reads this file (some modern desktop environments don't).

See man xmodmap for details.

  • I tried it myself, and it works fine. It's really unusual for xmodmap to "cripple" your keymappings (what exactly goes wrong?). What's the output of xmodmap -pm? – dirkt Nov 23 '16 at 6:48
  • Shrug It's your problem, not mine, but the correct way is to disable NumLock processing, and not to continuously poll. Polling is nearly always wrong, in all situations. If your system has a strange keyboard layout for some reason (e.g. some cyrillic, or whatever), then the way to go is to have a look at it: Maybe you use a modifier different from mod2 for NumLock. To get angry and deinstall xmodmap doesn't help. :-) But as I said, it's your problem, and your CPU usage. – dirkt Nov 23 '16 at 6:57
  • I happy to test your solution, but if I install a system into a VM with an English keyboard layout I know it will work: The window manager doesn't process the keymappings, X does. So if you dont' tell me your keyboard layout or whatever it is that causes problems on your system, I can install into a VM and test till I'm blue in the face, but we won't be closer to any solution. That's wasted time. :-) – dirkt Nov 23 '16 at 7:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.