numlockx does not turn num lock keyboard light on.

I confirm that "numlockx off;numlockx on" does not change the state of the numlock LED in any way. Pressing the numlock key itself does (but still won't enable the numpad for me as I wrote in bug 182421)

try this to have it auto start:

open a terminal window and type:

sudo gedit /etc/gdm/Init/Default

press enter

look for the line that says, “exit 0” and above this line add these extra lines:

if [ -x /usr/bin/numlockx ]; then

/usr/bin/numlockx on

fi

save the file and close gedit. Next time you reboot, numlock then you should be on by default

this works for me using hardy

For me, numlockx *does* correctly handle the keyboard led, at least under Ubuntu.

Under *Xubuntu* however, the led will NOT get lit. This has the rather strange effect that:
- If I use numlockx to turn NumLock on, then the numeric keypad will become functional, but the led will remain off;
- If I subsequently press the NumLock key, then the numeric keypad will be deactivated, but the led will become lit!

Rather confusing...

On Thu, 01 May 2008 18:56:19 -0000
luvr <email address hidden> wrote:

> For me, numlockx *does* correctly handle the keyboard led, at least
> under Ubuntu.
>
> Under *Xubuntu* however, the led will NOT get lit. This has the
> rather strange effect that:
> - If I use numlockx to turn NumLock on, then the numeric keypad will
> become functional, but the led will remain off;
> - If I subsequently press the NumLock key, then the numeric keypad
> will be deactivated, but the led will become lit!
>
> Rather confusing...
>
That's exactly what I'm experiencing. Ubuntu is fine, Xubuntu, not.

The suggestion made by Cipher_no1 above, does work: Turning on NumLock from "/etc/gdm/Init/Default" *will* turn on the keyboard LED.
Once the xfce environment is loaded, however, the "numlockx" utility will no longer touch the LED.

For me, this is an acceptable work-around for this issue--NumLock is now automatically turned on when I boot the system, *AND* the LED correctly reflects this fact. Since the NumLock key still functions correctly (i.e., it toggles both the NumLock status and the LED), I can live with it.

This seems to be an XFCE4 -specific issue. Reassigning to xfce4 metapackage.

> This seems to be an XFCE4 -specific issue. Reassigning to xfce4 metapackage.

Martin-Eric, it would certainly be nice if you looked back more than 24 hours. Reversing your changes. This has absolutely nothing to do with XFCE.

I tried some more and while "numlockx on/off" does not change the LED in any way, it does indeed toggle the numpad on and off.

The numlock key itself toggles both the LED and the function of the numpad.

So, when starting with a computer that has the LED in sync with the real state of the numpad which for this example we assume to be "on", then "numlockx off" will turn off the numpad but leave the LED on. The LED and the numpad function are now out of sync. Pressing the numlock key turns off the LED, but switches the numpad back on.

Rolf, I have looked at the whole thread. The point is, it works fine on GNOME and, according to someone at work, also on KDE. So, yes, it is an XFCE issue.

well, you haven't looked closely enough.

Take this hint: I don't use XFCE

BTW, comment 5 from darthanubis was a bit hard to read, so I will admit that I overlooked that he, too, experiences this only on XFCE.

Removing triaged tag and setting to confirmed. It looks like we are not 100% sure where and when this can and cannot be reproduced.

On Fri, May 2, 2008 at 4:32 PM, Rolf Leggewie wrote:

> BTW, comment 5 from darthanubis was a bit hard to read, so I will admit
> that I overlooked that he, too, experiences this only on XFCE.

Hence why I am veering towards blaming XFCE for skipping the X startup script.

> Removing triaged tag and setting to confirmed. It looks like we are not
> 100% sure where and when this can and cannot be reproduced.

Agreed on setting to Confirmed until a positive cause has been found.

--
Martin-Éric Racine
http://q-funk.iki.fi

Martin-Éric Racine wrote:

> Hence why I am veering towards blaming XFCE for skipping the X startup script.

I don't think that XFCE is skipping the startup script: After I installed numlockx on Xubuntu, the numeric keypad did become functional upon login--but the keyboard LED did not get lit.

It seems to me that the startup script "/etc/X11/Xsession.d/55numlockx" is the one that will execute numlockx upon login (there doesn't seem to be any other place where it might be done), so it must get run.

The issue is that XCFE will not turn the keyboard LED on. You can easily verify this by running the command "numlockx on" manually from a shell window: it *will* turn on NumLock mode, but it will not light the LED. Conversely, "numlockx off" will turn NumLock mode off again, but it will not dim the LED (if it was lit, e.g., after you pressed the NumLock key).

On Fri, May 2, 2008 at 10:07 PM, luvr wrote:
> Martin-Éric Racine wrote:
>
> > Hence why I am veering towards blaming XFCE for skipping the X startup
> script.
>
> The issue is that XCFE will not turn the keyboard LED on. You can easily
> verify this by running the command "numlockx on" manually from a shell
> window: it *will* turn on NumLock mode, but it will not light the LED.

What about the kernel's recent approach to separate the management of
LEDs from the keyboard driver? Could that be it?

Note: The same issue happens under Kubuntu (the KDE3 generation; haven't tested with Kubuntu Remix yet).

Thus:
- Under Ubuntu (GNOME), numlockx handles the keyboard LED just fine;
- Under Xubuntu (xfce), numlockx will not control the LED; however, you can run "numlockx on" from the "/etc/gdm/Init/Default" script, and the LED will be turned on allright;
- Under Kubuntu (KDE), numlockx will not control the LED either; I don't remember where the KDE Display Manager looks for its startup script, but I'm fairly confident that "numlockx on" can be run from that script, and the LED will be turned on right.

When are you guys going to listen?

> - Under Ubuntu (GNOME), numlockx handles the keyboard LED just fine;

For you and apparently a number of other people, good for you. But this is *NOT* generally the case, OK?

Just another confirmation on Kubuntu 8.04 with all the latest updates

Alfred

In kubuntu hardy if num lock led is off numpad works, if num lock is on numpad does not works.

I see similar 'out of sync' behavior on two Kubuntu Hardy machines, both updated from Gutsy. After a boot:
* the numlock LED is off
* the numpad is active

Pressing the numlock-button on the keyboard switches both: LED on, numpad inactive...

I only have access to one of the machines at the moment, so the next remarks may not be generally true, but I think they are:
* numlockx isn't installed
* after installing numlockx, the LED and numpad can be put in sync by executing 'numlock off'

This package would need to be rebuilt against current X.org dependencies to be fixed.

I can confirm this bug on Ubuntu (GDM/Gnome) Hardy (upgraded from Gutsy). I didn't have this problem on Gutsy, it has appeared probably after few upgrades on Hardy.
Rebuilding the numlockx package - as Martin-Éric recommends - fix this problem. See eg. this page for how to: http://www.cyberciti.biz/faq/rebuilding-ubuntu-debian-linux-binary-package/ However, you'll need to increase the version number (for example by adding new entry (1.1-8) into debian/changelog) or lock your custom build package, because the update-manager would like to use official version from repository.
Also there's probably no need to edit /etc/gdm/Init/Default since numlockx is launched from Xsession.d

Debian has an updated package which should be imported into Intrepid and backported to Hardy.

I can verify Wouter's experience: For KDE the NUMLOCK light operates backwards or opposite the actual keypad behavior.

A workaround is to manually edit /etc/kde3/kdm/kdmrc and immediately after [X-*-Greeter] add NumLock=On. Save and restart KDM.

Sorry for misinformation in my previous comment. Editing
/etc/gdm/Init/Default is still needed, otherwise Num Lock won't
activate on log off.
However, I've noticed strange behaviour of led light with custom
rebuild (it turns off after pressing key after logging in). I will do
more research on this issue, it can be related to other package (such
as Compiz or some Gnome stuff).

I had the same issue than you using lxde with openbox in hardy on a Pentium II: the Num Lock worked but the led did not work correctly.
I solved this issue in my system by just adding the following line at the end of the /etc/init.d/rc.local file:

numlockx on

It seems that numlockx firstly says that there is not Xorg present, but after this, when gdm and lxde starts, the led and numlock become on.

Thanks a lot to the community for their extraordinary job and also to the ubuntu team for the wonderfull Ubuntu!!!

I am on Ubuntu (GDM/Gnome) Hardy Heron (upgraded from Gutsy). I confirm that the Numlock LED has been operating opposite of the keypad behavior on my machine since one of the last Hardy updates.

The workaround posted by cprise on 2008-07-17 works for me. But I need to reboot rather than only restart kdm to let it take effect. Thanks.

I see that the numlockx package is not working for me - I'm using Ubuntu 8.04.1 under LTSP - the thin-clients do not seem to see the '55numlockx' script in /etc/X11/Xsession.d/ -- Just wanted to note that. I'm using Gnome, not XFCE or KDE, and this is happening. My users all have numbered usernames so this would be nice to fix. =)

Thanks!

Confirmation here that it affects Kubuntu Hardy, using KDM as a manager, and kde 3.5 (that is num pad works, starts in the right mode (on), but the light is inverted); It worked in previous versions (and I followed the upgrade route from previous versions, this is not a fresh install)

However, running numlockx on at any time sorts it out - guessing I just need to add that to a startup script somewhere (although it is not really a problem for me, so I haven't done this, as I would rather wait and see when a proper patch is applied).

Thanks.

While I still have numlock issues here in Jaunty Gnome (bug 182421), at least for me, the LED seems to be in sync with "the real situation". How is everybody else doing? If you are not on Jaunty, can you please test with a live CD or USB?

Cipher_no1's fix also works for me (in Hardy) but ONLY if I install numlockx FIRST.

Thanks, Cipher_no1.

mike

Same problem with debian/lenny ; numlockx 1.1-7 and icewm 1.2.35-1 :

async between leds status and real numlock status.

Using Karmic now, and the LED can be out of sync in certain situations.

i have this exact problem on Jaunty.

During boot the LED is on the the numpad produces numbers.

this continues to the Gnome login screen (can login using the numpad with the light still on).

Then as soon as i have logged in and ahve a desktop - the LED is off but the numlock is actually "on". The numlock button changes the LED to on then - but actually turns the numlock "off".

Any help? i have tried the numlockx solution - no change....

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue, in the default Ubuntu 9.10 install, that affects many people and is quick and easy to fix. So this bug can't be addressed as part of this project.

- This seems to be a hardware specific problem and doesnt exist in Karmic or jaunty , Hence not a papercut.
For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.

Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

Mac_v, the comments right above yours clearly state that this bug *does* exist in Jaunty and Karmic.

Rolf Leggewie, Oh! missed that...
But i'm unable to reproduce this problem. This seems hardware specific ,and hardware specific issues are not papercuts.

mac_v, may I kindly suggest you are more careful with your inferences? There have been a number of theories about what specifically triggers this bug. But your the first to suggest this may be a hardware-specific issue. How did you come to that conclusion? How do you know for sure? As you have not experienced this bug yourself, I can only conclude that you pulled that statement of fact out of thin air. That kind of guesswork presented as fact does not help anyone, it is outright destructive to those doing proper analysis. Please be more careful.

Given that the conclusions you made are not valid, I will revert your changes to the state of this bug. I guess the chances of this ticket making it into a paper cut are slim nonetheless.

Rolf Leggewie , Papercuts are supposed to be issue which are reproducible bugs in all systems.
Apart from myself[tested in a laptop and desktop],
I'v confirmed with a couple of other members that this is not a bug affecting all systems.
So i'm not pulling stuff out of thin air when i say , it seems hardware specific.

Kindly revert the status of the papercuts task.

Even worse!!

I'm on the recent Karmic, I did the workaround, but no change:

no LED AND no NumLock activation despite it worked on Jaunty on the same PC

Winux,

I couldn't see all the script in your screen print. This worked for me yesterday in a fresh Karmic install:

1. Enable universe and multiverse repositories;
2. sudo apt-get install numlockx;
3. In System > Administration > Startup Applications, add numlockx;
4. sudo gedit /etc/gdm/Init/Default;
5. look for the line that says, “exit 0” and above this line add these extra lines:

if [ -x /usr/bin/numlockx ]; then

/usr/bin/numlockx on

fi

save the file and close gedit. Next time you reboot, numlock then you should be on by default

http://ubuntuforums.org/showthread.php?t=153747
https://bugs.launchpad.net/ubuntu/+source/numlockx/+bug/218202

NOTE: I'm no expert--try at your own risk.

mike

the combination of bug 218202, bug 403472 and bug 182421 would form a great papercut. Despite it being three bugs at once that are not dupes, I think the work should be doable for an experienced programmer in one day or less. And it's certainly quite embarassing that Linux OSes can't properly deal with the numlock key and LED.

Vish, actually, this is not a hardware issue. It simply is that X and the Linux kernel got around separating LED handling from the keyboard driver, but numlockx's source code was never upgraded to #include the new headers for this.

I'll also point out that numlockx no longer has any upstream, plus that it no longer has a maintainer at the Debian end.

I would recommend that those who are interested in adopting this package contact me. We could probably move the upstream code's homepage to Launchpad and implement the necessary #ifdef to #include the missing headers, then figure out appropriate startup scripts for a variety of desktop environments, call this our new upstream tarball and upload this to Debian, then let the changes spread into Ubuntu via the automated archive synchronizations.

@Martin-Éric Racine: Thanks for clearing that up :)

@all... Would be nice if someone could adopt this package and fix this for lucid. [still not a papercut though, The papercut task was invalidated since it wasnt reproducible by others on the team as well. Numlock and the LED works for us here]

Vish, the code needs some love. You seem to operate under the mistaken assumption that a papercut has to affect everyone. That is not the case. Having numlock work correctly is quite important, I don't think anyone would want to argue with that. The number of people affected is sizable, look beyond just the three tickets mentioned and you will find many. Plus, the number of adversely affected users is only to grow with the progressing bitrot.

Martin-Eric, I generally gladly help out with maintaining orphaned packages. But I currently do maintain quite a few already. I'm a packager, not a coder, the latter is what this currently needs most urgently. You seem to have the knowledge. I hope you can either provide a patch directly (I'd do the packaging, but that should by then be trivial) or find some coder to mentor about this.

That said, adding a couple of #ifdef sounds easy enough even for somebody like me. Why does the package not fail compilation if there apparently are headers missing and what are those?

@Rolf Leggewie : Thank you for your interest in the papercuts project. and also offering to work on fixing this bug.
I'v tried to explain to you personally. But you assume to know more about a project than the actual team members.
Kindly leave the papercut task alone! It is counterproductive.

Hallo I have a variant of this bug. On my Acer 7530G I run Mint 9.0 (based on Isadora) and also Vector Linux 6.0 (based on Slackware). Both systems run XFCE4; the Mint kernel is 2.6.32.23 and the Vector kernel is 2.6.27.12.

On the Mint boot I installed numlockx from the standard repo (which I believe is derived from the Ubuntu repo); this includes the file /etc/X11/Xsession.d/55numlockx and the functionality is 100%. However on Vector I also installed numlockx and it does not work. It _does_ toggle the numpad functionality but leaves the LED out, and can cause the reverse operation of the LED described above (message #3)

OK you think, Vector's repo is out of date. But both executables are version 1.1, and both behave the same. That is, under Vector:
# cd /mnt/mint/usr/bin
# ./numlockx on
(that is, running the Mint executable under Vector) enables the numpad but not the LED. And under Mint:
# cd /mnt/vector/usr/bin
# ./numlockx on
(that is, running the Vector executable under Mint) enables the numlock _and_ the LED.

I don't know whether upgrading the kernel will help, I'll try that next (if I can, Vector is a bit iffy about updates). But this is 100% reproducible on my Acer, so I can definitely state that it's not an XFCE problem.

Any tips or advice would be welcome.

--- Derek

OK I tried a kernel update but Slackware 12.1 (which underlies Vector Linux) is still on kernel 2.6.24.5. I'm not clever enough to install a kernel except via the package manager so I can't get any further, unless anyone has suggestions . . . please?

--- Derek

I *don't* use numlockx. I have turned numlock on via systemsettings (KDE). Nonetheless I have the problem that when numlock is on, the LED is turned *off* and when numlock is off, the LED is on. Should be vice-versa. It only happens when I'm in X - it does work as expected in the virtual terminals.

This is occuring now with Maverick and in interesting way - if numlock is activated in BIOS settings, then it is on initially, but very shortly after the grub menu numlock LED goes OFF and stays off.

I previously had the numlockx on in XFCE startup and it worked before.

As I primarily use XFCE as desktop, I noticed the problem right away. LED is indicating numpad status wrongly on XFCE desktop, but not in tty's, although few toggles with numlock key are needed to get it right in tty's, but LED still stays "wrong way" on the desktop.

Ubuntu Lucid (and Karmic, too, if I remember correctly) didn't have this problem here, but some earlier release did.

The bug has returned in Maverick.

I want NumLock ON when the system prompts me for the username and the password, so I install the numlockx package and add the following lines to the "/etc/gdm/Init/Default" file (just above the "exit 0" line):

if [ -x /usr/bin/numlockx ]; then
   /usr/bin/numlockx on
fi

Under Maverick, NumLock will be turned on, but the NumLock LED will not.

Strange thing is, GNOME (i.e., the session that gets started for me when I log in) does appear to understand how to turn BOTH the NumLock state AND the NumLock LED on. The first time I logged in to GNOME, I pressed the NumLock key to activate the NumLock state (as well as the LED), and I left it that way. Ever since, whenever I log in, GNOME will restore the NumLock state AND turn on the LED for me.

Thus: GNOME KNOWS how to make sure that BOTH the NumLock state AND the NumLock LED are turned ON. Is there anyone here who could tell me what exactly GNOME does to turn on the LED, in addition to the NumLock state? Would it be doable to modify the numlockx utility to do the same? I wouldn't mind to try and do this myself, if only I knew where to start.

See http://bugs.freedesktop.org/show_bug.cgi?id=16145

This one fits better:
https://bugs.kde.org/show_bug.cgi?id=256255

Maybe this patch solves the problem: http://packages.debian.org/sid/x11-xkb-utils-udeb

Also seeing this problem in Natty

x11-xkb-utils-udeb is not a patch, would you mind please providing the url to the patch?

Almorca, we're waiting for feedback from what you meant with comment #54.

FWIW, obviously, a udeb is not a patch. Natty has the latest version from Debian unstable, so there is nothing to update. Furthermore, Debian does not patch the package in any way that could be related.

(from the unpacked unstable sources)
$ ls -1 x11-xkb-utils-7.6+2/debian/patches/
11_xkb_documentation_updates.diff
series

My guess is that Almorca meant to suggest to *install* the package in the hope there was something in it to help with the issue at hand. In any case, his was merely guesswork as well, he wasn't indicating any particular reason he felt the mentioned package could fix this.

Thus, resetting to New after two weeks of silence.

I'm having this problem since I upgraded to 10.10, I'm now on 11.04, same issue.

Status changed to 'Confirmed' because the bug affects multiple users.

Ubuntu 8.04 (hardy) reached end-of-life on May 12, 2011.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed.

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Ubuntu version. When you test it and it is still an issue, kindly upload the updated logs by running only once:
apport-collect <bug #>

and any other logs that are relevant for this particular issue.

https://cgit.freedesktop.org/xorg/xserver/commit/?id=45fb3a934dc0db51584aba37c2f9d73deff9191d