SUMMARY The default setting for NumLock is to leave the state unchanged, which makes sense to some degree. Unfortunately either Linux or SDDM turn NumLock always off, so the "leave unchanged" setting does not appear to be a good default value to me. What I'd expect would be "restore to last used setting" or something like that to be default. Also, Ideally that would already work at either Kernel or SDDM level, not sure what causes the problems there.
Copying over my comment from https://bugs.kde.org/show_bug.cgi?id=368063, since that was misplaced there: After witnessing the changes on the NumLock LED (before my keyboard did not have one), I am wondering whether this also has something to do with SDDM or Linux kernel options (at least when the option is set to "leave unchanged"). When booting, the NumLock LED is already off when SDDM shows up. If I remember correctly that is explicitly also the case when one has enabled NumLock to turn on when booting in the BIOS settings.
"Don't change" means exactly that: don't change it. So I don't see how this can possibly be a KDE bug.
Unless you mean the default setting should be changed of course. In that case, feel free to reopen.
(In reply to Wolfgang Bauer from comment #3) > Unless you mean the default setting should be changed of course. > In that case, feel free to reopen. Personally, I disagree though.
(In reply to Claudius Ellsel from comment #0) > Also, Ideally that would already work at either Kernel > or SDDM level, not sure what causes the problems there. In that case, it should be reported to the kernel or SDDM though. At least SDDM does have a setting for this: Numlock= Change numlock state when sddm-greeter starts. Valid values are on, off or none. If property is set to none, numlock won't be changed. Default value is "none".
(In reply to Wolfgang Bauer from comment #2) > "Don't change" means exactly that: don't change it. > > So I don't see how this can possibly be a KDE bug. Ah, I thought it meant don't change from the previous state (in the boot process), meaning if SDDM or some other previous applications changed it, it will remain unchanged. But apparently that is not what it means, instead it means that the value set in BIOS will be applied? In this case this is indeed intentional (apart from apparently downstream bugs where this does not work like on Tumbleweed or Manjaro).
(In reply to Wolfgang Bauer from comment #5) > (In reply to Claudius Ellsel from comment #0) > > Also, Ideally that would already work at either Kernel > > or SDDM level, not sure what causes the problems there. > In that case, it should be reported to the kernel or SDDM though. > > At least SDDM does have a setting for this: > Numlock= > Change numlock state when sddm-greeter starts. Valid values > are on, off > or none. If property is set to none, numlock won't be > changed. Default > value is "none". Yup, just wanted to make sure first that I get the scope of the problem correctly. As I wrote before, NumLock is already off for SDDM. Does the `none` value there also means that it is supposed to read the BIOS value or just that it doesn't touch NumLock at all meaning when the Kernel has turned it off it will just stay at that?
(In reply to Claudius Ellsel from comment #6) > (In reply to Wolfgang Bauer from comment #2) > > "Don't change" means exactly that: don't change it. > > > > So I don't see how this can possibly be a KDE bug. > > Ah, I thought it meant don't change from the previous state (in the boot > process), meaning if SDDM or some other previous applications changed it, it > will remain unchanged. But apparently that is not what it means, instead it > means that the value set in BIOS will be applied? In this case this is > indeed intentional (apart from apparently downstream bugs where this does > not work like on Tumbleweed or Manjaro). No, it does exactly mean that Plasma itself won't change it at all. Plasma won't touch the NumLock state on start. So, if it is set to on by anything else in the boot process, it will stay on. Or if it was off, it will stay off. (In reply to Claudius Ellsel from comment #7) > (In reply to Wolfgang Bauer from comment #5) > > (In reply to Claudius Ellsel from comment #0) > > > Also, Ideally that would already work at either Kernel > > > or SDDM level, not sure what causes the problems there. > > In that case, it should be reported to the kernel or SDDM though. > > > > At least SDDM does have a setting for this: > > Numlock= > > Change numlock state when sddm-greeter starts. Valid values > > are on, off > > or none. If property is set to none, numlock won't be > > changed. Default > > value is "none". > > Yup, just wanted to make sure first that I get the scope of the problem > correctly. As I wrote before, NumLock is already off for SDDM. Does the > `none` value there also means that it is supposed to read the BIOS value or > just that it doesn't touch NumLock at all meaning when the Kernel has turned > it off it will just stay at that? For SDDM, it means exactly the same. With "none" (the default), it won't change the state, NumLock will remain the same it was before. And AFAIK, the kernel will always turn it OFF. Anything else are distribution services during boot. In openSUSE there is a kbdsettings.service that's run during boot, that is supposed to turn it on/off according to the settings in /etc/sysconfig/keyboard. (the default is to read the BIOS setting, but at least that's currently broken in Tumbleweed and therefore always results in OFF)
Ah, then I misunderstood your comment on the openSUSE tracker and thought that would generally apply to KDE in general. Then this issue still remains relevant for KDE in my opinion. Basically I think it will be beneficial to for example have a fourth option that will use the BIOS setting (or/and another one that restores this setting from the previous session). This is at least what I as a user would expect, not sure whether it makes sense from an architectural / distribution point of view. Ideally openSUSE would "upstream" the things they do for this and then use the setting from KDE instead of relying on a hidden service for this.
(In reply to Claudius Ellsel from comment #9) > Then this issue still remains relevant for KDE in my opinion. Basically I > think it will be beneficial to for example have a fourth option that will > use the BIOS setting (or/and another one that restores this setting from the > previous session). I'm not sure it's possible from the KDE/Plasma side, and I don't see why Plasma should change it to be different than on the login screen. That's my opinion, of course. > Ideally openSUSE would "upstream" the things they do for this and then use > the setting from KDE instead of relying on a hidden service for this. That has no relevance to KDE though. It's a service that runs on boot and also affects text mode.
(In reply to Wolfgang Bauer from comment #10) > (In reply to Claudius Ellsel from comment #9) > > Then this issue still remains relevant for KDE in my opinion. Basically I > > think it will be beneficial to for example have a fourth option that will > > use the BIOS setting (or/and another one that restores this setting from the > > previous session). > I'm not sure it's possible from the KDE/Plasma side, and I don't see why > Plasma should change it to be different than on the login screen. > > That's my opinion, of course. It already is possible to set the setting to "on" and "off", so "remember" or "use BIOS value" might also work. If Plasma shouldn't change it to be different from the login screen than even the already existing options are a bit pointless. But if it can be already done at login screen level, that would be even better, I guess. > > Ideally openSUSE would "upstream" the things they do for this and then use > > the setting from KDE instead of relying on a hidden service for this. > That has no relevance to KDE though. It's a service that runs on boot and > also affects text mode. I agree that the service itself has no relevance. But the NumLock features are something I'd really like to see in KDE as well. But I might be wrong here and getting that correct is up to every distribution, because it has to be done at a lower level (unfortunately both distros with KDE that I have used, Manjaro and Tumbleweed, currently don't seem to get this right, so I thought a more centralistic solution might help).
(In reply to Claudius Ellsel from comment #11) > (In reply to Wolfgang Bauer from comment #10) > > (In reply to Claudius Ellsel from comment #9) > > > Then this issue still remains relevant for KDE in my opinion. Basically I > > > think it will be beneficial to for example have a fourth option that will > > > use the BIOS setting (or/and another one that restores this setting from the > > > previous session). > > I'm not sure it's possible from the KDE/Plasma side, and I don't see why > > Plasma should change it to be different than on the login screen. > > > > That's my opinion, of course. > > It already is possible to set the setting to "on" and "off", so "remember" > or "use BIOS value" might also work. That's the question. But why do it on the Plasma level? Actually "Don't change" is supposed to do that IMHO. > If Plasma shouldn't change it to be different from the login screen than > even the already existing options are a bit pointless. But if it can be > already done at login screen level, that would be even better, I guess. I wouldn't consider them pointless. On a multi-user system, one user could choose to have a different setting than all others do, and might not even have the rights to change them on a system level. Again, my opinion of course. But I'm sure there is a reason why it was implemented like this years ago.
Your use cases for the already existing options also apply to the ones I am suggesting, though. On a multi-user system, a user might want to restore his previous used state (and this cannot be done at login screen level). I understand now, though that apart from those use cases it might be better to have the functionality implemented somewhere else, although I am not sure whether it can be done at a central point, so all distributions can benefit, maybe SDDM? But that would be off-topic.