Numlock again :-(

I have a variant on what seems to be a recurring issue. I use two KDE sessions, with one user on F7 and a different user on F8. For user 1 I have set numlock on. However then the session for user two on F8 always starts with numlock off, despite setting the KDE setting to on, and the keyboard setting in YAST to on. Does anyone know how I can start multiple graphical sessions with all the numlocks stating “on”?


AFAIK, this is a SSDM issue.
BTW, some of us are experiencing a “usually Num-Lock indicated as being off” issue when we login to a KDE Plasma 5 session.
Can’t remember if there are KDE KF5 and/or SDDM Bug reports raised against these issues.

No, it’s not.
SDDM is not involved when switching VTs, and actually it doesn’t touch the NumLock state at all by default.

It may help to make SDDM explicitly turn on NumLock in /etc/sddm.conf though:


See also “man sddm.conf”.

Can’t remember if there are KDE KF5 and/or SDDM Bug reports raised against these issues.

Sure, I even remember one filed by you on KDE’s bugzilla… :wink:
But IMHO it’s neither a bug in KF5 nor Plasma nor SDDM.

Btw, YaST’s setting has no effect, as the SUSE-specific patch that evaluated that option got removed from systemd in Leap 42.1.
Will be back in 15.0 though, as a separate kbdsettings.service.

Looking at the process tree on this system, the parent process of “sddm” is “systemd” and there’re 2 child processes of “sddm”: “X” and “sddm-helper”.
My “startkde” process is a child of “sddm-helper”.
My “kdeinit5” process is a child of “systemd” and my “ksmserver” process is a child of “kdeinit5”.

If I start a new, parallel, user session, the “sddm” process starts 2 new child processes: “X” and “sddm-helper” – both user “root”.
The new “sddm-helper” process has a new child “startkde” process for the “new” parallel (Test) user session.
There’s also a new “kdeinit5” process for the “new” parallel (Test) user session with a new “ksmserver” process for that user.

  • And, I’m noticing that, since the parallel session has been started, the “Num-Lock” lamp on the keyboard repeatedly “turns off” – after I’ve turned it on again …

So, the 64-dollar question: who, or what, is managing the switching between the two KDE Session Managers?

Xorg and/or systemd, I’d say, although the kernel or udev may be involved here as well.

Btw, I see the same behaviour as you once mentioned (i.e. the NumLock LED turns off when I press Shift, although NumLock itself is still on) with kdm , another indication that it’s not SDDM’s “fault”… :wink:

PS, see also the latest comment in 1017294 – multiple users => num lock light "on" and num keypad "off" :

In normal situation, kbd always sets LED together with NumLock status change.

I am not sure what is the source of the problem. It could be kernel, kbd, X or even systemd or boot process or splash screen implementation. It could be bad setting of LEDs mask.

To debug the problem in the lowese level, you should check /sys/class/leds in the inconsistent state. Is trigger properly set to kbd-numlock? Does brightness correspond with the current LED state?