This is driving me mad, (especially as I had some serious problems, and had to reboot/log-out/in many hundreds of times!)
In BIOS set to boot up NumLock
In YAST2 .etc/sysconfig editor, > Hardware>Keyboard>KBD_NUMLOCK=YES (also tried setting this to BIOS)
In System Settings > Input Devices > Keyboard “NumLock on KDE startup” set to YES
But still, when I reboot, the Numlock is correctly set to on. Sometime during openSuse loading, and before KDM, the NumLock is switched off. KDE does not switch it back on again.
I have considered getting the USB id and trying to match that to one of the ‘branded’ keyboards in the drop-down list in System settings. But it is openSuse which is switching it to OFF.
(the id is 1241:1503, identifies as Belkin keyboard, BTW)
Thank you nrickert. I must say that I feel that the ‘problem/bug/feature’ is rather in something that openSuse does whilst in the boot process (it switches Numlock to OFF) . My login password has numerals (like most, I guess) and it would be more sensible to allow the NumLock to be on when we reach the KDM login screen?
However I agree that KDE also has a problem, in that it fails to switch NumLock to ON when it loads, despite it being explicitly told to do that in system settings.
Yes, except that the kernel is pretty much in charge at that point. As best I can tell, this is a kernel change and affects all distros, not just opensuse.
Yes, my login password has numerals. But it also has letters. So I have never used the numeric keypad for password, which I perhaps why I don’t see it as a problem for KDM.
The setting should be on line 364 of the kdmrc file
Reading it now I realise there is no space between # and Numlock
Try searching for #Numlock=Off in the file.
This is a configuration file, so it can be completely different on different systems.
Just add that line to the “[X-*-Greeter]” section as already mentioned.
But IMHO this won’t help you at all anyway, as this only affects the login screen.
According to your bug report, numlock is turned off by xinitrc/Xsetup during login because the file that specifies to turn it on doesn’t get created any more.
I think the easiest workaround would be to call “numlockx on” at login as Xsetup would do. You can add scripts to be called at login in Systemsettings/Configure Desktop->Startup and Shutdown->Autostart e.g.
> This is a configuration file, so it can be completely different on
> different systems.
> Just add that line to the “[X-*-Greeter]” section as already mentioned.
>
> But IMHO this won’t help you at all anyway, as this only affects the
> login screen.
He wants the numeric keyboard for typing the password, so yes, it should
help
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-10-21 21:36, wolfi323 wrote:
>
> robin_listas;2670536 Wrote:
>> He wants the numeric keyboard for typing the password, so yes, it should
>> help
>>
> Well, apparently he wants to have it ON in KDE as well. For this it
> won’t help, I think.
>
> I somehow missed the part about typing the password though.
Yes, of course. I should have said that he wants that keyboard active
everywhere, which makes sense, of course. We all do, typically.
It is a longstanding nuisance. I do not type keywords using the keypad
before getting to the desktop precisely because the numlock status is
not consistently on or off, and I can not rely on it. I got used to the
numbers on top of the keyboard for this very reason. Since many years.
Either that, or always remember to check the LED.
(On the “screensaver”, if you make a mistake on the password
entry, it punishes you with a 5 second delay-penalty. Even
on the first attempt. Then it delays you even more telling
how many failed attempts there were, as if I didn’t know
(the interval between failed and successful attempts tells
it is not an intruder)).
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-10-22 05:26, nrickert wrote:
>
> robin_listas;2670575 Wrote:
>> Either that, or always remember to check the LED.
>
> If there is an LED to check
Ouch
There are such thing, LED-less keyboards? I have not seen them, or so
rarely that I don’t remember.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
> On 2014-10-22 05:26, nrickert wrote:
> >
> > robin_listas;2670575 Wrote:
> >> Either that, or always remember to check the LED.
> >
> > If there is an LED to check
>
> Ouch
>
> There are such thing, LED-less keyboards? I have not seen them, or so
> rarely that I don’t remember.
>
Oh yes! It’s one reason why I went back to wired keyboards wherever
possible. Mind you, that was a few years ago so they may be less common
now.
–
Graham P Davis, Bracknell, Berks.
openSUSE 13.2-RC1 (64-bit); KDE 4.14.1; AMD Phenom II X2 550 Processor;
Kernel: 3.16.3; Video: nVidia GeForce 210 (using nouveau driver);
Sound: ATI SBx00 Azalia (Intel HDA)
Or indeed if the LED can be relied upon. Now after some fiddling, as evidenced in this thread above, I am sitting at the desk, the NumLock LED resolutely off. But if I use the keypad, it is, in fact, switched ON
12346546848556456486464564564545318454…>:(>:)
… and there is this situation, where on some laptops, the external keyboard will not change the LED on the laptop, but the built-in keyboard will.
Or, this will happen in Linux, while it works properly under Windows.
Logitech wireless keyboards are a good example of the latter, as Logitech only supplies the driver for Windows, not Linux, and their driver handles the LEDs and onscreen notices correctly, while the same does not happen in Linux.
