I selected NumLock on KDE Startup: Turn ON but NumLock is remains OFF after login. (Even though the BIOS turns it ON.) Reproducible: Always Steps to Reproduce: 1. Configure NumLock on KDE Startup: Turn ON 2. Login to KDE Actual Results: NumLock is OFF Expected Results: NumLock is ON
Same here. BIOS turns numlock on, kcm_keyboard turns it off no matter how it's set.
I can't confirm this on Arch running plasma 5.9.5.
Related bug: The Num Block key status isn't remembered between sessions: (https://bugs.kde.org/show_bug.cgi?id=383962)
*** Bug 383962 has been marked as a duplicate of this bug. ***
*** Bug 373646 has been marked as a duplicate of this bug. ***
Adding [General] Numlock=on to /etc/ssdm.conf supposedly works around this. Can anyone reproduce in Plasma 5.11.3 or later?
In Plasma 5.11.3, if in "/etc/ssdm.conf" section "Numlock", I remove "on" numlock turns off after reboot.
*** Bug 388156 has been marked as a duplicate of this bug. ***
*** Bug 411304 has been marked as a duplicate of this bug. ***
Here is my experience of this bug : It happens in KDE Neon 5.17 (user edition). It hasn't happened in Kubuntu 18.04. Numlock option in keyboard settings has no effect. If I put 'Nummlock=on' in sddm.conf, I have 2 cases : - if autologin is on, I get directly to the desktop and numlock if off. - if autologin is off, I get to the login in SDDM with numlock on and it stays on when I get to the desktop. The only way I managed to get numlock on at startup with autologin in KDE Neon is by installing good old numlockx.
Seems a bit like this setting does not have an effect at all. Maybe there is some collision with SDDM?
Correction: This setting actually has an effect for me. It was set to "Leave unchanged" before, which left NumLock turned off, probably because it has been turned off during startup (that might be a different problem to look into). However, when I turn this setting to on, it works as expected for me. Can you confirm this still happens for you with the current version?
I've switched to Kubuntu 20.04 since my previous message. Numlock is on in keyboard settings and it works as expected.
(In reply to funkypou from comment #13) > I've switched to Kubuntu 20.04 since my previous message. Numlock is on in > keyboard settings and it works as expected. Alright. Maybe it is fixed with the more current plasma versions. Although it looks like also in the past there have been configurations where it worked and some where it did not (like your experience on KDE Neon). If anybody is still experiencing this, please comment. I suggest to wait some time and close this if nobody has commented.
Not fixed for me, I rebooted this morning. Operating System: KDE neon 5.19 KDE Plasma Version: 5.19.4 KDE Frameworks Version: 5.72.0 Qt Version: 5.14.2 Kernel Version: 4.15.0-112-generic OS Type: 64-bit Processors: 8 × AMD FX(tm)-8350 Eight-Core Processor Memory: 7.8 GiB of RAM Graphics Processor: GeForce GT 1030/PCIe/SSE2
(In reply to Greg Lepore from comment #15) > Not fixed for me, I rebooted this morning. > > Operating System: KDE neon 5.19 > KDE Plasma Version: 5.19.4 > KDE Frameworks Version: 5.72.0 > Qt Version: 5.14.2 > Kernel Version: 4.15.0-112-generic > OS Type: 64-bit > Processors: 8 × AMD FX(tm)-8350 Eight-Core Processor > Memory: 7.8 GiB of RAM > Graphics Processor: GeForce GT 1030/PCIe/SSE2 Thanks! I assume you did also make sure to select the option to have NumLock on in the Systemsettings Keyboard settings?
Yes, the setting was set to "Turn on" both before and after the reboot, but no numlock.
*** Bug 428504 has been marked as a duplicate of this bug. ***
This is meant to be set by the kded keyboard plugin. Does it work after a "kded5 --replace"?
Not sure when I should try 'kded5 --replace', after boot? It didn't do anything. I switched to a new motherboard and the problem remains, including after setting NumLock to On in BIOS.
(In reply to Greg Lepore from comment #20) > Not sure when I should try 'kded5 --replace', after boot? After logging in, yes. > It didn't do > anything. I switched to a new motherboard and the problem remains, including > after setting NumLock to On in BIOS. Ok, so that rules out any race condition during boot/login and leaves the code in the kded. Just to be sure, what's the output of `kreadconfig5 --file kcminputrc --group Keyboard --key NumLock`? I don't have a num block on my keyboard here, so I can't really reproduce the issue...
kreadconfig5 --file kcminputrc --group Keyboard --key NumLock produces a "0"
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Bug is still occurring, information has been provided to prevent closure.
I have the same issue on OpenSUSE Tumbleweed. Also, possibly related, the compose key doesn't work even though I've enabled it in the KDE settings. I've had to use a script running "setxkbmap -option compose:menu" to make it work.
*** Bug 414207 has been marked as a duplicate of this bug. ***
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 Num Lock 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.
Since this bug is (at least originally) about cases where the preference to always turn NumLock on is explicitly set, I created another one generally tracking the problem that this is not the default value: https://bugs.kde.org/show_bug.cgi?id=432107.
(In reply to Greg Lepore from comment #22) > kreadconfig5 --file kcminputrc --group Keyboard --key NumLock > > produces a "0" That means "Don't change". But this bug report is about "NumLock not is not turned on at start, although the preference for it is set to `on`" So can anybody reproduce the problem when it is set to "on" in KDE/Plasma's settings?
(In reply to linus.kardell+kdebugs from comment #25) > I have the same issue on OpenSUSE Tumbleweed. The defaults for Tumbleweed are broken currently, see https://bugzilla.opensuse.org/show_bug.cgi?id=1179295. That's a downstream problem though.
Created attachment 135174 [details] NumLock Settings
See attachment. NumLock is set to "Turn on" and kreadconfig5 --file kcminputrc --group Keyboard --key NumLock shows "0". These appear to be incompatible settings. I think my screenshot is accurately portraying the submitters report, isn't it?
(In reply to Greg Lepore from comment #32) > See attachment. NumLock is set to "Turn on" and kreadconfig5 --file > kcminputrc --group Keyboard --key NumLock shows "0". These appear to be > incompatible settings. > > I think my screenshot is accurately portraying the submitters report, isn't > it? Yes, I think it is. I just wanted to get rid of unrelated problems. Thanks for clarifying your case.
(In reply to Wolfgang Bauer from comment #33) > (In reply to Greg Lepore from comment #32) > > See attachment. NumLock is set to "Turn on" and kreadconfig5 --file > > kcminputrc --group Keyboard --key NumLock shows "0". These appear to be > > incompatible settings. > > > > I think my screenshot is accurately portraying the submitters report, isn't > > it? > Yes, I think it is. > > I just wanted to get rid of unrelated problems. > > Thanks for clarifying your case. Btw, is this X11 or Wayland, by chance?
X11.
(In reply to Greg Lepore from comment #32) > See attachment. NumLock is set to "Turn on" and kreadconfig5 --file > kcminputrc --group Keyboard --key NumLock shows "0". These appear to be > incompatible settings. > > I think my screenshot is accurately portraying the submitters report, isn't > it? Hm, I am not an expert, but it seems as if changes of this preference are not transferred correctly to the settings file? Out of curiosity, does the output of that command change if you change the preference in the settings?
Yes, the settings change. Here is the mapping: Turn on = 0 Turn off = 1 Leave unchanged = 2 Which are different from Comment 29.
(In reply to Greg Lepore from comment #37) > Yes, the settings change. Here is the mapping: > > Turn on = 0 > Turn off = 1 > Leave unchanged = 2 > > Which are different from Comment 29. Yes, sorry, my mistake. From plasma-desktop/kcms/keyboard/kcmmisc.cpp: enum TriState { STATE_ON = 0, STATE_OFF = 1, STATE_UNCHANGED = 2, }; So the problem is apparently *not* that the setting is not saved correctly.
(In reply to Wolfgang Bauer from comment #38) > From plasma-desktop/kcms/keyboard/kcmmisc.cpp: It's kcmmisc.h of course.
I have the same problem, that Numlock setting has no effect at all. Plasma version 5.20.4, X11.
I have this problem in a intermittent way in 5.21.4
(In reply to linnets from comment #40) > I have the same problem, that Numlock setting has no effect at all. > Plasma version 5.20.4, X11. Well, it does work fine here. I have another idea though: I do remember bug reports where ibus interfered with KDE's keyboard settings. I have no idea whether it also changes the NumLock state, but maybe that would be a possible reason? I.e. do you have ibus installed? And does it help to uninstall it? (ibus itself, libibus shouldn't matter) (In reply to Ninguém from comment #41) > I have this problem in a intermittent way in 5.21.4 What exactly does "intermittent way" mean?
I had ibus, but removing it doesn't help
I have ibus installed. But, now the Numlock setting WORKs again (really strange, I did not do anything unusual) - that I even forgot that I had this bug. (In reply to Wolfgang Bauer from comment #42) > I have another idea though: > I do remember bug reports where ibus interfered with KDE's keyboard settings. > I have no idea whether it also changes the NumLock state, but maybe that > would be a possible reason? > > I.e. do you have ibus installed? > And does it help to uninstall it? (ibus itself, libibus shouldn't matter)
I have this problem again, after reinstall Linux.
This is an issue for my laptop. I have the correct Keyboard model selected from the dropdown menu (Acer | Acer laptop) and then in the NumLock on Plasma Startup The "Turn on" radio button is selected. When I restart the NumLock key is NOT on. I have to manually toggle the NumLock key on my keyboard to turn it on. This is not the expected behavior. SOFTWARE/OS VERSIONS OS: Arch Linux x86_64 Kernel: 5.14.12-arch1-1 (available in About System) KDE Plasma Version: 5.23.1 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2
(In reply to yizel7 from comment #46) > This is an issue for my laptop. I have the correct Keyboard model selected > from the dropdown menu (Acer | Acer laptop) and then in the NumLock on > Plasma Startup The "Turn on" radio button is selected. When I restart the > NumLock key is NOT on. I have to manually toggle the NumLock key on my > keyboard to turn it on. This is not the expected behavior. > > SOFTWARE/OS VERSIONS > OS: Arch Linux x86_64 > Kernel: 5.14.12-arch1-1 > (available in About System) > KDE Plasma Version: 5.23.1 > KDE Frameworks Version: 5.87.0 > Qt Version: 5.15.2 Graphics Platform: X11
(In reply to yizel7 from comment #46) > This is an issue for my laptop. I have the correct Keyboard model selected > from the dropdown menu (Acer | Acer laptop) and then in the NumLock on > Plasma Startup The "Turn on" radio button is selected. When I restart the > NumLock key is NOT on. I have to manually toggle the NumLock key on my > keyboard to turn it on. This is not the expected behavior. > > SOFTWARE/OS VERSIONS > OS: Arch Linux x86_64 > Kernel: 5.14.12-arch1-1 > (available in About System) > KDE Plasma Version: 5.23.1 > KDE Frameworks Version: 5.87.0 > Qt Version: 5.15.2 I now have an external keyboard plugged into my laptop and the situation is the same. NumLock is not on when I turn on my computer even though it is set to be turned on in System Settings.
Is this being worked on? It is driving me crazy.
Raising priority due to number of duplicates.
Assuming that "numlockx off/on" works, but "kded5 --replace" does not: - Is "keyboard daemon" enabled in "background services"? - What's the output of "gdb -ex 'break XkbLockModifiers' -ex r -ex bt -ex quit --args kded5 --replace"? - What's the output of "gdb -ex 'break KModifierKeyInfo::setKeyLocked' -ex r -ex bt -ex quit --args kded5 --replace"? (Answer "yes" if gdb asks something)
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Remember having this problem years ago, went away but can't remember why. Started happening again a few weeks ago. Currently using plasma 5.26.3
(In reply to Fabian Vogt from comment #51) > Assuming that "numlockx off/on" works, but "kded5 --replace" does not: > - Is "keyboard daemon" enabled in "background services"? > - What's the output of "gdb -ex 'break XkbLockModifiers' -ex r -ex bt -ex > quit --args kded5 --replace"? > - What's the output of "gdb -ex 'break KModifierKeyInfo::setKeyLocked' -ex r > -ex bt -ex quit --args kded5 --replace"? > > (Answer "yes" if gdb asks something) Didn't see this comment when i reopened this bug report. Seems like the keyboard daemon was for some reason not running. after starting the daemon the numlock turned on. I will check in the following days if this permanently fixes this issue.
It should. If you have reason to suspect that the daemon not being running automatically is a bug, please open a new bug report. Thanks!
just to reensure, that the daemon not started is the issue here. this numlock issue drove me nuts since three month or so. other isssue: i've disabled key repeating on longer press and this also didn't work as exspected. since i've started the daemon manualy also this feature is going .. i'm quite confident in saying: i've never ever changed the behavior of this autostart setting. i've actualy didn't know about this one to the day. (running neon) closing words: i do not feel very comfortabel with a setting, where 0 (zero) is for *en*abling something. same with "do not change setting" just deletes the whole NumLock line in kcminputrc. if one never touched the setting, no line in the rc file feels right, but the moment, the user *does* set the behavior this explicit setting should reflect in a file. just my 2ct, sorry
>kreadconfig5 --file kcminputrc --group Keyboard --key NumLock >0 >echo $XDG_SESSION_TYPE >x11 >ps -A |grep kglobalaccel >1229 ? 00:00:00 kglobalaccel5 Nothing helped except: >apt install numlockx
This is a fairly old bug report and the code has changed a lot since it was reported. There's a very good chance the issue you're experiencing is caused by something else, even if the outward symptoms look and feel the same. Can you please submit a new bug report? Thank you!
(this thread is linked in other places) New bug report can be found here - https://bugs.kde.org/show_bug.cgi?id=485940 Adjacent bug report is also here (on=on but last-state==on=off) - https://bugs.kde.org/show_bug.cgi?id=454478