NumLock will not turn on when I login to a KDE 4.0 session

Bug #184472 reported by integr8e on 2008-01-19
46
This bug affects 3 people
Affects Status Importance Assigned to Milestone
KDE Base
Won't Fix
Medium
kdebase-workspace (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: kde4

I have NumLock set to turn on upon logging in to my KDE 4.0 session in "System Settings KDE4 -> Keyboard & Mouse -> NumLock on KDE Startup", however, it remains off.

That's about it :-)

Che Guevara (che-guevara-3) wrote :

If you set it to off (yeah that's right) will it now be on?

Changed in meta-kde4:
status: New → Incomplete
integr8e (integr8e) wrote :

Sorry for the really, really late reply (I was away from my home computer when I read your reply, and kinda' forgot about it :-) ). Anyway, it does seem to turn on when set to remain off - it seems strange nobody else has noticed this.

Erik Harren (linux-aceh) wrote :

I've got the same issue but maybe more general. All settings done in 'System Settings KDE4 -> Keyboard & Mouse' are ignored even speed-settings for the mouse.

Is there any possibility to check that?

Erik Harren (linux-aceh) wrote :

I turned numlock to off - result: numlock comes back after login but goes off after a while (ca. ten secs).

Erik Harren (linux-aceh) wrote :

As it is for me it seems '~/.kde4/share/config/kcminputrc' won't be used.
It doesn't matter which settings are changed there is no effect in the kde4-seesion.

Terence Simpson (tsimpson) wrote :

Are you still experiencing this problem with current KDE4 packages?

integr8e (integr8e) wrote :

Yes, I still have to have NumLock set to turn off to have it turn on at boot...are you not experiencing this bug?

Terence Simpson (tsimpson) wrote :

I use a laptop, so I don't use numlock

Hi Terence!

Terence Simpson wrote:
> Are you still experiencing this problem with current KDE4 packages?

I do, although the Num-Pad even without Num-Lock-Lights are shown
neither in my Keyboard nor in gkrellm. Afair i had to set Numlock - from
always on to off and after some updates i had to switch to always-on again.

regards,
Erik.

Changed in meta-kde4:
status: Incomplete → New

Version: (using KDE 4.2.0)
Compiler: gcc 4.3.3-1 (GNU Compilier)
OS: Linux
Installed from: Unspecified Linux

System Info:
------------
System: Arch Linux
Desktop: KDE 4.2
Compiler: gcc 4.3.3-1 (GNU Compiler)
------------

First, activate and enable the NumLock feature using the following menu commands:

[System > System Settings > Keyboard & Mouse > Click on "Turn On" for "NumLock on KDE Startup"]

When rebooting the computer or restarting KDE, initially, but for a very short time, the NumLock Light indicator is "On", and then after a brief period, it shuts off after that. The light seems to shut off after various keyboard activity, such as typing the "free -m" command line in the KDE Konsole (Terminal) for example. However, NumLock functionality is still there, hence, enabling one to type numbers using the keypad even though the Light Indicator is off.

Is this issue going to be assigned to anyone to review?

dmoyne (daniel-moyne) wrote :

This bug is a "classico" and as a "classico" is back ; I have the latest release of KDE 4.2.1 and in my case this option :
"System Settings KDE4 -> Keyboard & Mouse -> NumLock on KDE Startup"
has entirely disapeared from the scene and this is a very good idea because as far as I know the "numlock" option is a kdm option because we want numlock "on" to possibly enter numbers in password dont' we ?

I used this trick :
In file /etc/kde4/kdm/Xsetup I added this :
if [ -x /usr/bin/numlockx ]; then
    /usr/bin/numlockx on
fi

but I think it is possible to modify in the same directory the kdmc file by adding this line somewhere :
NumLock=On
in the greeter section but I have not tried because my kdmc repeats some sections in stange manner and I have first to check wether this file is correctly structured before possible modifications.

Regards

Jonathan Thomas (echidnaman) wrote :

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at: https://bugs.kde.org/show_bug.cgi?id=183308

affects: meta-kde4 (Ubuntu) → kdebase-workspace (Ubuntu)
Changed in kdebase-workspace (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Changed in kdebase:
status: Unknown → New

*** Bug 187410 has been marked as a duplicate of this bug. ***

Confirmed here on KDE 4.3.2 (Arch Linux)

Jonathan Thomas (echidnaman) wrote :

Hi there!

Thanks for reporting this bug! Your bug seems to be a problem with the KDE program itself, and not with our KDE packages. But don't worry! This issue is being tracked by the KDE developers at: http://bugs.kde.org/show_bug.cgi?id=183308
Once fixed in KDE, it will be included in Kubuntu once the KDE version the fix is in in reaches Kubuntu.

Thanks!

Changed in kdebase-workspace (Ubuntu):
status: Triaged → Invalid

Confirmed on KDE 4.3.4 (Kubuntu).

Any xkb options used? any keyboard layouts configured? if yes could you please attach ~/.kde/share/config/.kxkbrc ?

Created attachment 43505
kxkbrc

> Any xkb options used? any keyboard layouts configured?

None that I'm aware of, but I attached the file as requested.

This problem seems to be unrelated to KDE's keyboard module.
Do you by any chance run some LED daemon, like http://manpages.ubuntu.com/manpages/hardy/man8/ledd.8.html ?

There's a very similar problem https://bugs.kde.org/show_bug.cgi?id=232364 which was fixed by stopping ledd daemon.

No, ledcontrol isn't and never was installed. There's also no ledd in ps aux.

*** This bug has been confirmed by popular vote. ***

Confirming on KDE 4.4.3 on Arch Linux. No application possibly touching the state of led is installed

Changed in kdebase:
status: New → Confirmed

Any news on this? Any improvements with newer X.org or KDE 4.5?

I can't reproduce this problem on either Mandriva or openSUSE for either KDE 4.4.4 or 4.5.

Taking to account three reports were from Arch Linux (and one from Kubuntu which might be ledd problem) I would think it's related to the distro packaging.

I am marking this bug as "need more info" for now, but if there's any additional information please add it to the bug and I'll take a look.

It's fixed for me.

I'm not sure whether it's the same issue, but when I switch the user (start another session) and I switch back the light indicator shuts off even though num lock is still on. Both users have the setting to turn on the numlock at startup enabled.

LED is re-enabled when I switch on and off numlock. I've configured keyboard layout switcher to indicate the keyboard layout using the Scroll lock LED. When I switch layouts and the scroll lock led is switched on/off, the numlock LED is re-enabled too.

The system is Arch Linux with KDE 4.4.5

Changed in kdebase:
status: Confirmed → Unknown

Yes, this no longer appears to be a problem for me, at least as of 4.4.5. I have not checked on Lukas's issue (Comment #14), though.

Created attachment 50788
kxkbrc

It still is an issue for me, using KDE 4.5.0 on Kubuntu 10.04.1. I can reproduce everything from comment #14, and also using Suspend to RAM: after waking up, the LED is off, even though NumLock is active. I have no LED daemon such as ledcontrol installed, and my keyboard layouts are "us(altgr-intl)" and "de".

I was hit by this bug again today. Kubuntu Maverick.

(In reply to comment #17)
> I was hit by this bug again today. Kubuntu Maverick.

And led daemon is not used? That seems to be most probably cause at least for *Ubuntu distros.

(In reply to comment #18)
> (In reply to comment #17)
> > I was hit by this bug again today. Kubuntu Maverick.
>
> And led daemon is not used?

Nope, sorry.

(In reply to comment #0)
> Version: (using KDE 4.2.0)
> Compiler: gcc 4.3.3-1 (GNU Compilier)
> OS: Linux
> Installed from: Unspecified Linux
>
> System Info:
> ------------
> System: Arch Linux
> Desktop: KDE 4.2
> Compiler: gcc 4.3.3-1 (GNU Compiler)
> ------------
>
> First, activate and enable the NumLock feature using the following menu
> commands:
>
> [System > System Settings > Keyboard & Mouse > Click on "Turn On" for "NumLock
> on KDE Startup"]
>
> When rebooting the computer or restarting KDE, initially, but for a very short
> time, the NumLock Light indicator is "On", and then after a brief period, it
> shuts off after that. The light seems to shut off after various keyboard
> activity, such as typing the "free -m" command line in the KDE Konsole
> (Terminal) for example. However, NumLock functionality is still there, hence,
> enabling one to type numbers using the keypad even though the Light Indicator
> is off.

I can confirm this issue as well. Once the light is off it swaps where num lock on is off and num lock off is on. Kubuntu 10.10 KDE 4.5.3. Any info I can submit?

Changed in kdebase:
importance: Unknown → Medium
Changed in kdebase:
status: Unknown → Incomplete

Still an issue with KDE 4.6.2 on Kubuntu. Long-time issues like this - keypad status is that of reverse LED - sadly display some staggering non-professionalism, I'm beginning to think.

I also experienced this bad behavior too, I mean: System > System Settings > Keyboard & Mouse > Click on "Turn On" for "NumLock on KDE Startup", then system reboot: the numlock status LED is OFF although my numeric keypad is enabled, and the way around: if I press the numlock key, the numlock status LED is ON but my numeric keypad is disabled. Pb is 100% reproducible (I'm running Kubuntu Natty 11.04 with KDE 4.6.2). I don't have the numlock status LED transiently switching to ON just after the reboot as reported in comment #1. Also, if I check "Leave unchanged" for "NumLock on KDE Startup" in my system settings, I may have my numlock status LED correctly handled, but then after some while, the LED status gets de-synchronized with the actual numeric keyboard status (I did not identified one single action that triggers the de-synchronization so far).

The bug is classified as "waitingInfo": which info do you miss for investigating this issue further, which issue being pending for some while now (I do not remember from which KDE version this pb appears, but I did not have any problem at all with numlock handling one or two years ago).

(In reply to comment #22)
> The bug is classified as "waitingInfo": which info do you miss for
> investigating this issue further, which issue being pending for some while now
I tried and could not reproduce this problem on Mandriva 2010.x, OpenSuse 11.3 and 11.4 and Fedora 14 and 15. I also tried KDE 4.4, 4.5, 4.6 and master (upcoming 4.7). It was also tried on several X.org versions.
It's not quite clear from the comments but looks like the problem in Arch distro is gone (at least for some users) so it leaves only Kununtu to misbehave.
I could change the status to WORKSFORME (which is the right one when it can't be reproduced), but I am willing to look at it again if somebody can reproduce it on some other distribution I have access to (that's why it's still in WAITINGFORINFO).
Also there's several possibly related bugs in x.org which are still open:
https://bugs.freedesktop.org/show_bug.cgi?id=32921
https://bugs.freedesktop.org/show_bug.cgi?id=35005
https://bugs.freedesktop.org/show_bug.cgi?id=8411
https://bugs.freedesktop.org/show_bug.cgi?id=12434
https://bugs.freedesktop.org/show_bug.cgi?id=3037

Now there's at least one bug in Ubuntu which was seen under Gnome so also is not related to KDE:
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/92482

(In reply to comment #21)
> Still an issue with KDE 4.6.2 on Kubuntu. Long-time issues like this - keypad
> status is that of reverse LED - sadly display some staggering
> non-professionalism, I'm beginning to think.
Yes, I agree, that's why I don't use Kubuntu or and don't recommend it to anybody :)

I can reproduce it on both OpenSuSE 11.4 and Arch. It doesn't happen when rebooting but the symptoms are exactly the same. The LED shortly switches on to indicate that numlock is on, but then it the LED switches off while the numlock is still enabled.

Steps to reproduce:
1. create two users
2. log into as the first user and enable numlock
3. use "Switch User" and log into the second user
4. switch back to the first user user using Ctrl + Alt + Fx, and unlock the session

Result:
in most cases the LED indicating numlock state is is off while numlock is still enabled. However the KDE session for 2nd user seems to handles numlock LED correctly.

If the bug doesn't show up, try to switch the numlock on/off randomly while switching between users. Actually, after few tries I was able to break numlock indicator for the second user too.

(In reply to comment #24)
> I can reproduce it on both OpenSuSE 11.4 and Arch. It doesn't happen when
> rebooting but the symptoms are exactly the same.
Lukas, thanks a lot for good description, I was trying to reproduce the original report (the problem on booting up) that's why I didn't see it.
The problem with switching VT's is a x.org bug though, see https://bugs.freedesktop.org/show_bug.cgi?id=9964 (Wrong state of NumLock LED with 2 X servers started or state of NumLock LED is not preserved)
I was able to reproduce it with OpenSuse 11.4 (X server 1.9.3) even without KDE - I just started two simple X sessions and the problem with numlock is there. So you may want to subscribe to the x.org bug.
It also may be somewhat related to https://bugs.freedesktop.org/show_bug.cgi?id=35005 (NumLock state on two USB keyboard LED-s), interesting bit from that bug: "Laptop keyboards have its own driver / hardware numlock handling and therefore these can have independent numlock state" - this probably complicates the problem even more.

Just tried VT switching in Fedora 15 (X.Org X Server 1.10.1) and the numlock problem is still there. I am marking this as UPSTREAM.

@Andriy Rysin: forgot to mention that the pb occurs on a USB keyboard connected to my T400 laptop, which has already an internal keyboard. The Numlock status LED on this laptop internal keyboard is correctly handled and I never noticed so far any discrepancy on that keyboard between the numlock LED status and the actual status of the numeric keyboard. The pb occurs with the external USB keyboard only, and I don't need so far to switch betwen VT console for the pb to appear, neither I need to switch between two active users. As far as I can see, the pb rather relates to https://bugs.freedesktop.org/show_bug.cgi?id=35005: seems as if the external keyboard does not get the NumLock LED state message on reboot: only the internal keyboard gets it.

"I am willing to look at it again if somebody can reproduce
it on some other distribution I have access to (that's why it's still in
WAITINGFORINFO)" > Do you want me to carry out some traces, or dump some debug information, that might be helpful for identifying the source of this bug? If so, please let me know, I would be keen helping you further (and don't start the distro war please: the pb so far seems not related to the distro but the xorg server, isn't it).

@anderlia Unfortunately as you already mentioned it's a problem in x.org, and I don't have an easy way to fix it in KDE. I suspect some things could be done a bit better if we support configuring multiple keyboards (https://bugs.kde.org/show_bug.cgi?id=177889) which might make it a bit more explicit as to which keyboard numlock state goes but even then the problems in x.org will probably create other issues we'll have to deal with.
I'd say this needs to be fixed in upstream or we can just wait for Wayland and hope there will be no problems like these :)

Seems the problem is fixed from 12.04 Precise Pangolin onwards (KDE 4.8.2, xserver-xorg 1:7.6+12ubuntu1). The NUMLOCK LED indicator on my external USB keyboard is now consistent with the actual status of the numercal keyboard, and I can correctly set the NUMLOCK status at startup time in my KDE system settings either to OFF/ON/LEAVE UNCHANGED. I tested the threee options and they all work fine. As far as I am concerned, 183308 bug can be set to CLOSE/RESOLVED.

It seems to be partially fixed (KDE 4.8.2) on Arch. It doesn't happen when I have the first keyboard layout selected, but it still sometimes happen when I have the second keyboard layout selected while switching to another user.

To reproduce under Arch with KDE 4.9.4 using a PS2 keyboard:

1. Set Num Lock to be on in the System Settings.
2. Log out/in.
3. Switch to another virtual console with ctrl-alt-F1
4. Switch back with alt-F7
5. [Do more or less anything you like, but do not press caps-lock or numlock]
6. Press any shift, ctrl, or alt key and watch the LED go out.

(In reply to comment #31)
> To reproduce under Arch with KDE 4.9.4 using a PS2 keyboard:

Confirmed under Kubuntu with KDE SC 4.9.4 using USB keyboard.

Same problem here, with Slackware and KDE 4.8.2.

Only, I noticed something different too: I frequently use the
compose key (spanish locale), and that functionality _also_ stops working.
This is very annoying, as it alwys stops at the moment I most need it (Murphy's Law).

I don't actually use KDE as window manager (I use XFCE), but Slackware is KDE
based and running some kde programs starts the kdeinit4 daemon.
Another strange thing: I can re-enable Compose, using xmodmap, but it
stops working again after a random time.

I very much suspect both problems (LED and Compose) are related. Does anyone
using Compose notice this?

John

could you please attach. xsession-errors and Xorg.0.log right after it happens?

Andriy,

I will do that - I am now testing a suggestion which seems to make sense. I removed
'setxkbmap us' from my bashrc. I read a report that after calling setxkbmap the problem
is activated.

Either way, I'll report back tomorrow.

John

Hello guys,

I can quite firmly state that the problem went away here. Apparently, after
removing 'setxkbmap us' from my bashrc, the issues disappeared.

I have been using the machine for more than 48 hours now, and I still have
the Compose key working, _and_ the numkey has not switched off in all
this time.

Of course I cannot confirm this 100%, but the change is really notable.

Maybe someone coudl find a reason for setxkbmap causing this effect?
I'll leave it like this some more, then try putting it in again to check if the
problem reappears...

John

tags: added: raring

Can confirm this bug under KDE 4.11.3 with Tanglu 1.0 (Debian). Steps to reproduce:

Activate numlock on login
Standby
Resume
Numlock is active, LED goes on briefly then back off

I don't use a compose key.

Regards,

Alad

I reported upstream that NumLock is broken after using setxkbmap (as mentioned in comment 35):
https://bugs.freedesktop.org/show_bug.cgi?id=78012

Confirmed on KDE 4.14.2 under Debian GNU/Linux 8.1 (jessie)

This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.

Changed in kde-baseapps:
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.