[plasmashell] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off
https://bugs.kde.org/show_bug.cgi?id=432107 Claudius Ellsel changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Severity|normal |wishlist Resolution|INTENTIONAL |--- --- Comment #9 from Claudius Ellsel --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off
https://bugs.kde.org/show_bug.cgi?id=432107 --- Comment #8 from Wolfgang Bauer --- (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) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off
https://bugs.kde.org/show_bug.cgi?id=432107 --- Comment #7 from Claudius Ellsel --- (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? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off
https://bugs.kde.org/show_bug.cgi?id=432107 --- Comment #6 from Claudius Ellsel --- (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). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off
https://bugs.kde.org/show_bug.cgi?id=432107 --- Comment #5 from Wolfgang Bauer --- (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". -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off
https://bugs.kde.org/show_bug.cgi?id=432107 --- Comment #4 from Wolfgang Bauer --- (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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off
https://bugs.kde.org/show_bug.cgi?id=432107 --- Comment #3 from Wolfgang Bauer --- Unless you mean the default setting should be changed of course. In that case, feel free to reopen. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off
https://bugs.kde.org/show_bug.cgi?id=432107 Wolfgang Bauer changed: What|Removed |Added Resolution|--- |INTENTIONAL Status|REPORTED|RESOLVED CC||wba...@tmo.at --- Comment #2 from Wolfgang Bauer --- "Don't change" means exactly that: don't change it. So I don't see how this can possibly be a KDE bug. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off
https://bugs.kde.org/show_bug.cgi?id=432107 --- Comment #1 from Claudius Ellsel --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 432107] Default NumLock settings to leave the state unchanged will result in NumLock turned off
https://bugs.kde.org/show_bug.cgi?id=432107 Claudius Ellsel changed: What|Removed |Added Keywords||usability -- You are receiving this mail because: You are watching all bug changes.
