https://bugs.kde.org/show_bug.cgi?id=432107

--- Comment #8 from Wolfgang Bauer <wba...@tmo.at> ---
(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.

Reply via email to