Peculiar, Nagging Problem with Num Lock at SDDM

English Install/Boot/Login
,
1

Hello everyone, today I am hoping to find a bit of help with a pestering issue on one of my Tumbleweed installs. This issue has me stumped, it’s so odd therefore I am not necessarily expecting a solution here (not necessarily doubting y’all’s skill, it’s just that I cannot even find anything on this by searching and it seems really niche)… nevertheless I will try! Bear with me. :slight_smile:

Okay, here goes:

I have my system set up so that Num Lock is set to on when I land on the Login Screen (SDDM). Setting this up is always a simple procedure that I execute by simply editing /etc/sysconfig/keyboard via Nano.

What is happening is the Num Lock appears to be activated when I land on SDDM; the keyboard’s Num Lock indicator light is on, but the system registers no input on the numpad. I will have to hit the Num Lock once more, the indicator light strangely remains lit, and only then will the system register input from the numpad. It’s peculiar in that the light is on, but it’s behaving as if it’s not!

  • I have attempted with multiple keyboards of various layouts. Problem persists.

  • On this particular machine is a fresh TW install, there have been no hardware changes, nor has there been any BIOS or firmware updates. On this machine, Num Lock was behaving as normal before the fresh TW install.

  • None of my other machines has this problem, I have never encountered it before across a great many installs on any machine.

  • System Settings > Keyboard > NumLock on startup is set to “Turn On.” This is the same for all my systems. I nevertheless tried playing with this setting, but to no good end.

  • All settings in YaST Sysconfig Editor (Keyboard > KBD_NUMLOCK) look good.

I even copypasted the entire file found in /etc/sysconfig/keyboard from a working machine into the problem machine, and still the issue persists.

Is this an earth-shattering issue? No. Can I live with this? Yes. But, my goodness, you all know how it is when something just doesn’t work right and the problem is not so much the inconvenience as much as it is not understanding what the heck is happening. Besides, I do wish to know if there is an underlying issue or at least educate myself.

If someone can lend a hand I would be deeply appreciative.

2

Is the problem machine by any chance your only one using UEFI?

On the problem machine, is the initial SDDM behavior matched on all vttys?

On the problem machine, is there a BIOS setup option with NUM set to on? On the others?

Are login screen and vttys matched on all other machines?

# inxi -S
System:
  Host: gb970 Kernel: 6.13.8-1-default arch: x86_64 bits: 64
  Console: pty pts/0 Distro: openSUSE Tumbleweed 20250417
# cat /etc/sddm.conf.d/general.conf
[General]
InputMethod=
Numlock="on"
# grep -i num /etc/sysconfig/keyboard
# NumLock on? ("yes" or "no" or empty or "bios" for BIOS setting)
KBD_NUMLOCK="yes"

On boot, NUM is on and in sync with LED in KDM3.

# systemctl list-unit-files | egrep 'dm.s|legacy'
display-manager-legacy.service              enabled         enabled
sddm.service                                disabled        disabled
xdm.service                                 disabled        disabled
# systemctl stop display-manager-legacy.service
# systemctl start sddm.service
# systemctl list-unit-files | egrep 'dm.s|legacy'
display-manager-legacy.service              enabled         enabled
sddm.service                                disabled        disabled
xdm.service                                 disabled        disabled

KDM3 (display-manager-legacy.service) shut down and SDDM started, turning off NUM led and numpad in the process. :frowning:

I have no idea why everything is so anti-NUMlock in Linux, all the way back to kernel, when BIOS is set to NUM=ON, and the keyboard has a NUM pad which is NUM enabled when Grub takes control. The thing is, in openSUSE it’s easier to keep NUM enabled than in every other distro I’ve tried, apparently due to whatever takes note of the content of /etc/sysconfig/keyboard’s KBD_NUMLOCK= setting. I wish quality keyboards existed that are unable to have NUM off. NUM with any keyboard that has both cursor-only and separate NUM pads is a nonsensical legacy IBM’s PC AT’s 101 key keyboard gave us by someone who hated bookkeepers and accountants, people who can routinely input accurately >100 characters per minute without even looking at fingers, keyboard or display. :frowning:

1 Like
3

i am having the same issue
numlock USED TO!!! work . However now it dose not
and i have tried basically everything to have it stay on

i have put it up to some odd bug

1 Like
4

I can confirm that it is not working for me (using SDDM Wayland).

1 Like
5

Try adding NumLock=on to /etc/sddm.conf

1 Like
6

For SDDM Wayland at least that has no effect.

1 Like
7

As shown in comment 2, Numlock="on" in /etc/sddm.conf.d/general.conf fails.

1 Like
8

What did work for me was the following was to turn on ‘NumLock on startup’ via to System Settings > Keyboard, then System Settings > Login screen (SDDM) and click on ‘Apply Plasma Settings…’

The relevant configuration files touched via the above are
/var/lib/sddm/.confg/kcminputrc
and
/etc/sddm.conf.d/kde_settings.conf

It took effect as soon as I logged out of the desktop session, and presented with the SDDM login screen again.

1 Like
9

So it appears Numlock=on in the SDDM config file is not sufficient by itself. To make it work,
/var/lib/sddm/.config/kcminputrc file requires

[Keyboard]
NumLock=0

as well.

1 Like
10

Also described here…

2 Likes
11

Okay, I cannot thank you all enough. I am upvoting everyone in this thread! Truly, my gratitude.

Since yesterday I have been keeping up with the replies, carefully combing through each one and trying various things, comparing files between my various machines, etc. Nothing has worked. I am actually just going to chalk this up to some cleverly hidden bug, or perhaps some PBKAC issue where I cannot recall screwing up. I just… don’t know.

After reading what you all submitted and exhausting my efforts with that knowledge, I went ahead and did a fresh install to see what would happen. Lo and behold, my Numlock behaved normally after simply editing (“/etc/sysconfig/keyboard”) via Nano as I normally do on all my TW installs.

Some important points for anyone who may stumble upon this in the future:

  • To the best of my ability, I could not Occam’s razor my way out of this. So things like NumLock on boot being disabled in BIOS, improper settings in YaST, malfunctioning keyboards, etc. were all checked and double checked and found not to be an issue.

  • The system giving me this problem is indeed UEFI, as are all but one of the other TW systems I have. To be specific, the mobo of the system in question is an Asus TUF Gaming Z790-Plus WIFI with the latest BIOS at the time of this writing.

  • I made absolutely no changes to BIOS and reinstalled TW from the very same files of the very same bootable USB (created via Rufus). No reformatting of the USB at all.

  • I tried a mix of keyboards, from $400+ custom CannonKeys to $5 no name rubber dome boards. I tried multiple usb ports. The problem persisted.

  • Changing login screen (e.g. Breeze, Elarun, maya, etc.) did not produce fruitful results.

  • Followed deano_ferrari’s advice and links. Read through it all, tried all solutions. Problem persisted.

Okay, that’s all the mostly useful info. Now I’ll ramble a bit.

Interestingly, only nuking the OS worked on this. Nuking an OS to fix something is sort of a nerd sin in my eyes but this problem vanquished me, I’ll admit. Reinstall: what a cheap, gritty solution, but sometimes a gal has to do what she ain’t proud of the get results :rofl:

I joke a bit, but reinstalling while keeping in place certain controls (e.g. not playing around in BIOS, using the very same bootable drive/files, etc.) was part of my troubleshooting. I wanted to see if the problem persisted through a reinstall. If it did, I would have started looking at hardware troubleshooting. After all attempts failed, I started to expect hardware and wanted to check for that.

@ mrmazda, my goodness… like you I have no clue why Linux is so anti NumLock. Just anything dealing with numpads in general can be difficult. It’s not just Linux. Like I am into custom keyboards, and anyone who is in that hobby will tell you that finding good keyboards with numpads is like finding a four-leaf clover.

When I wrote in the OP, “Is this an earth-shattering issue? No. Can I live with this? Yes” apparently I was wrong rofl.

Seriously, though. Thanks to you all.

12

Well, I didn’t exactly stumble upon the thread itself, but have been stumbling about the incentive to enable Numb-Lock [sic].

Why need this?

Personal opinion only … this has never entered my thoughts. Our Dell laptops have dedicated / separate arrow / PgUp PgDn keys, number pad.

The desktop has an Ergo Pro sawed in half keyboard (that’s Canadians for ya).

We aren’t bookkeepers, not CPAs … and although our passwords are mixed with numbers, we aren’t under a time constraint to enter credentials and tap Enter.

So, what’s the advantage, other than “I have to tap on N.L. key” at every boot?

13

Honestly, it hadn’t crossed my mind either until this topic came up. But the OP explained pretty clearly that they were trying to understand why ‘Num Lock’ wasn’t active at the SDDM login screen—something they thought was already configured.

A perfectly valid question from the OP, IMHO. In the end, it really comes down to personal preference. :wink:

15

Not the same as ours: MatiasErgoPro-keyboard

16

Correct. I understand the “why not active at SDDM” part.

My question was, “why does it need to be active?”
:+1:

17

Because at least two responders in this topic want it to be that way. (Hence, why I dove in to understand what is required for SDDM Wayland at least.) Use what works for you. :wink:

2 Likes