![]() Registered Member ![]()
|
Is there any option for that?
|
![]() Registered Member ![]()
|
System Settings > Input Devices > Keyboard > Hardware > NumLock on KDE Startup
|
![]() Registered Member ![]()
|
This option is set to "Leave unchanged". I do have numlock service at default runlevel:
https://wiki.gentoo.org/wiki/FAQ#How_do ... on_boot.3F I also use evdev for keryboard and mouse. https://wiki.gentoo.org/wiki/Evdev https://wiki.gentoo.org/wiki/Xorg/Guide ... e_keyboard I do not want to KDE settings to interfere in to my settings, so I usually do not touch KDE's keyboard settings. Numlock worked in KDE4 before. In Plasma 5 it became broken: it doesn't set on on startup anymore. If I will change it to "Turn on" in KDE settings and apply, then it will most likely add options which I do not want for the keyboard besides Numlock. What should I do to unbroken it? P.S. Maybe there's some option to add to some settings file? |
![]() Manager ![]()
|
have you tried using the computer's bios for this?
|
![]() Registered Member ![]()
|
I don't have option for "Numlock on" in BIOS. Everything worked fine before upgrade to Plasma 5.
|
![]() Registered Member ![]()
|
Then Plasma5 does not touch/change the state of NumLock on login at all obviously, that's the point of this option. If it is turned off, it will stay turned off. If it is turned on (by something else), it will stay turned on. But AFAIK, the kernel itself turns off NumLock at boot, so you need *something* to turn it on again.
No idea what that is, there is no specifc numlock service in openSUSE (the generic display-manager.service will turn on NumLock here if set to do so in /etc/sysconfig/.). So I cannot help you with that. But it seems that it is not working correctly or is configured wrong. In openSUSE, the display-manager.service by default takes the BIOS setting. This doesn't work with my USB keyboard here, though it does on the same system with an older PS/2 keyboard (so probably a bug in the BIOS, NumLock just flashes briefly before the boot menu appears and is off at the boot menu already). But setting it to on explicitly works fine here, the setting is located in /etc/sysconfig/keyboard (but that probably doesn't apply to Gentoo).
Maybe it was turned on in KDE4's keyboard settings? Your distribution might have changed the defaults for KDE4, but not Plasma5...
The NumLock settings only affect NumLock, nothing else. |
![]() Registered Member ![]()
|
Maybe it is a problem with numlock service then. It probably doesn't startup correctly or it's the problem with openrc (it shows that the service started but it actually not?). If I won't fix it in low level, I'll try to change this setting in Plasma 5. That you.
|
![]() Registered Member ![]()
|
Sorry, but Numlock is set to off on every relogin to Plasma 5 from SDDM. Even after "rc-service numlock restart". It can be also SDDM resetting numlock too. Who knows. I will try to investigate it further.
|
![]() Registered Member ![]()
|
It looks like SDDM bug. SDDM reset Numlock to off, although there are no options "Numlock=" inside /etc/sddm.conf.
|
![]() Registered Member ![]()
|
No, it's probably not SDDM bug. Numlock service in Gentoo only affects linux ttys (fbcon usually). If smb uses X/Wayland, this will likely have their own settings. So, for SDDM the solution would be to place "Numlock=on" string inside /etc/sddm.conf. And for Plasma would be to change above mentioned Numlock setting (or not change it after SDDM).
|
![]() Registered Member ![]()
|
I checked on KDE Neon developer stable branch and it works just fine. That means, it is not SDDM bug, or it might be your package version specific bug.
|
![]() Registered Member ![]()
|
This works for me, cool. Thank you very much ![]() |
![]() Registered Member ![]()
|
Does the option to leave things unchanged even make sense, if the kernel switches numlock off at boot?
In this case it might be better to remember the last state when Plasma was used. |
![]() Registered Member ![]()
|
Still working here! Had to make the file with Kate text editor, reboot and there we go. Done. Thanks! |
Registered users: Bing [Bot], Evergrowing, Google [Bot], rblackwell