numlockx does not turn num lock keyboard light on.

[darthanubis]

Binary package hint: numlockx

numlockx does not turn num lock keyboard light on. The keypad works, although the light is not on. This has always worked, now in Hardy it does not?

[Rolf Leggewie (r0lf)]

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)

[Cipher_no1 (cipher-no1)]

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

[luvr (luc-vanrompaey)]

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...

[darthanubis (darthanubis)]

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.

[luvr (luc-vanrompaey)]

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.

[Martin-Éric Racine (q-funk)]

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

[Rolf Leggewie (r0lf)]

> 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.

[Rolf Leggewie (r0lf)]

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.

[Martin-Éric Racine (q-funk)]

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.

[Rolf Leggewie (r0lf)]

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.

[Martin-Éric Racine (q-funk)]

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

[luvr (luc-vanrompaey)]

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).

[Martin-Éric Racine (q-funk)]

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?

[luvr (luc-vanrompaey)]

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.

[Rolf Leggewie (r0lf)]

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?

[AlfredPr (apratt)]

Just another confirmation on Kubuntu 8.04 with all the latest updates

Alfred

[Alessandro Ghersi (alessandro-ghersi)]

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

[Wouter Horré (wouterh)]

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'

[Martin-Éric Racine (q-funk)]

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

[Sndirsch-suse (sndirsch-suse)]

A simulated Caps Lock key press makes the logical and the physical states of
the Caps Lock out of sync. This causes a problem as one of OpenOffice's
functionality - correct accidental use of cAPS LOCK key - relies on this
feature of X.

The attached test program toggles the logical state of the Caps Lock key, but
the LED indicator does not get toggled.

The "correct accidental use of Caps Lock" feature in OOo is based on this
test program. Explanation of this feature:

Let's say you open Writer, with your Caps Lock key turned on (but you don't
know it's on). Start typing a sentence e.g. "Here comes the Sun" but it comes
up as hERE because of the Caps Lock. As soon as you hit space after the first
word, Writer will then correct that to 'Here' and turn off the Caps Lock key.
Calc, Impress and Draw all do this.

This LED indicator still worked with xserver 1.3.0.0, but not any longer with
1.4.0.90.

[Sndirsch-suse (sndirsch-suse)]

Created attachment 16798
CapsLockToggle.c

Compile it with 'gcc -Wall -o CapsToggle CapsToggle.c -l Xtst'.

[Peter Hutterer (peter-hutterer)]

On Thu, May 29, 2008 at 12:37:12AM -0700, <email address hidden> wrote:
> A simulated Caps Lock key press makes the logical and the physical states of
> the Caps Lock out of sync. This causes a problem as one of OpenOffice's
> functionality - correct accidental use of cAPS LOCK key - relies on this
> feature of X.

confirmed with git master.

Now, with 1.4 and master having similar subsystems I think I found what the
issue is.
1.3 and before had one physical device as the "core keyboard". 1.4 and beyond
however feature a "virtual core keyboard" (VCK), all physical input devices
are extension keyboards.

If you hit a key on the keyboard, the core event is generated by the VCK, and
an XI event by the actual keyboard. The LED change then happens when the XI
event is passed through xkb (the LEDS on the virtual keyboard change too,
but, well...).

If you use xtest for core events, the server picks the VCK and processes it
accordingly - but, because it is the VCK you don't see the LED change.
To fix this, you essentially have to pick which devices need the LED state
updated and run it past them as well. Which gets a bit iffy, if you have
multiple keyboards, some of which have CL on and some of which have it off
(which AFAIK should work now). Which ones do you pick? Do you switch CL on? or
off?

Comments?

[Sndirsch-suse (sndirsch-suse)]

As you can see in the test program

a) I didn't pick any special keyboard at all
b) it's just a toggle (no explicit turn on/off)

I attach a more complex test program for turning numlock on/off or toggle it,
which still works with xserver 1.4.0.90. Not sure how to adjust it to get also Capslock working. I'm afraid numlock and Capslock needs to be handled slightly different.

[Sndirsch-suse (sndirsch-suse)]

Created attachment 16806
numlockx-1.1.tar.gz

[Martin-Éric Racine (q-funk)]

Upstream hasn't maintained numlockx code in ages. Already, Debian/Ubuntu had to autoreconf to accommodate the modular X.org structure. If anybody feels like taking over upstream maintenance and issuing a patched source with proper #ifdef to compile this on recent X. please do so and inform me of the new upstream tarball location, so that I update the debian package. Thanks!

[Daniel Stone (daniels)]

On Thu, May 29, 2008 at 01:28:54AM -0700, <email address hidden> wrote:
> If you hit a key on the keyboard, the core event is generated by the VCK, and
> an XI event by the actual keyboard. The LED change then happens when the XI
> event is passed through xkb (the LEDS on the virtual keyboard change too,
> but, well...).
>
> If you use xtest for core events, the server picks the VCK and processes it
> accordingly - but, because it is the VCK you don't see the LED change.
> To fix this, you essentially have to pick which devices need the LED state
> updated and run it past them as well. Which gets a bit iffy, if you have
> multiple keyboards, some of which have CL on and some of which have it off
> (which AFAIK should work now). Which ones do you pick? Do you switch CL on? or
> off?
>
> Comments?

I think the only thing that makes sense is for XTest to use GKE to
generate events for the keyboard that last sent core events. Principle
of least surprise and all -- why mangle other keyboards?

[Sndirsch-suse (sndirsch-suse)]

(In reply to comment #5)
> Upstream hasn't maintained numlockx code in ages. Already, Debian/Ubuntu had
> to autoreconf to accommodate the modular X.org structure. If anybody feels
> like taking over upstream maintenance and issuing a patched source with
> proper #ifdef to compile this on recent X. please do so and inform me of the
> new upstream tarball location, so that I update the debian package. Thanks!

This is completely off-topic. Please discuss this issue with Lubos Lunak via private mail, IRC or whatever. numlockx is *not* the problem here at all!

[Peter Hutterer (peter-hutterer)]

> --- Comment #6 from Daniel Stone <email address hidden> 2008-05-29 03:20:01 PST ---
> I think the only thing that makes sense is for XTest to use GKE to
> generate events for the keyboard that last sent core events. Principle
> of least surprise and all -- why mangle other keyboards?

that would actually be easy now. MDs keep dev->u.lastSlave around, so we could
just route through that. For 1.4, this would be slightly more complicated.
First thought is to just add two fields to inputInfo.

[Daniel Stone (daniels)]

(In reply to comment #8)
> > --- Comment #6 from Daniel Stone <email address hidden> 2008-05-29 03:20:01 PST ---
> > I think the only thing that makes sense is for XTest to use GKE to
> > generate events for the keyboard that last sent core events. Principle
> > of least surprise and all -- why mangle other keyboards?
>
> that would actually be easy now. MDs keep dev->u.lastSlave around, so we could
> just route through that. For 1.4, this would be slightly more complicated.
> First thought is to just add two fields to inputInfo.

possibly not so complicated -- what about the following patch:
diff --git a/dix/getevents.c b/dix/getevents.c
index 2fd4e54..79366f8 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -414,6 +414,10 @@ GetKeyboardValuatorEvents(xEvent *events, DeviceIntPtr pDev, int type,
     CARD32 ms = 0;
     deviceKeyButtonPointer *kbp = NULL;

+ if (pDev == inputInfo.keyboard)
+ pDev = dixLookupPrivate(&inputInfo.keyboard->devPrivates,
+ CoreDevicePrivateKey);
+
     if (!events)
         return 0;

(assuming all callers of GK{,V}E are happy with this.)

[Sndirsch-suse (sndirsch-suse)]

Daniel, is the patch for 1.4 or git master? I would be happy to try it with 1.4.0.90.

[Daniel Stone (daniels)]

On Thu, May 29, 2008 at 06:50:35AM -0700, <email address hidden> wrote:
> Daniel, is the patch for 1.4 or git master? I would be happy to try it with
> 1.4.0.90.

Should work with both, modulo merge detritus (although MPX may get rid
of the private and replace it with ->lastSlave). The point is that, if
GetKeyboardEvents is called with inputInfo.keyboard as the device, to
change the device to the last device which used it to send events. It's
definitely not suitable for applying or distributions though, as I
haven't checked all callers of GK(V)E; it may have bad side effects.

[Julien Cristau (jcristau)]

On Thu, May 29, 2008 at 07:08:33 -0700, <email address hidden> wrote:

> --- Comment #11 from Daniel Stone <email address hidden> 2008-05-29 07:08:33 PST ---
> On Thu, May 29, 2008 at 06:50:35AM -0700, <email address hidden>
> wrote:
> > Daniel, is the patch for 1.4 or git master? I would be happy to try it with
> > 1.4.0.90.
>
> Should work with both, modulo merge detritus

Modulo devPrivates rework, too, as 1.4 doesn't have dixLookupPrivate().
You'll need pDev->devPrivates[CoreDevicePrivatesIndex].ptr I think.

Cheers,
Julien

[Peter Hutterer (peter-hutterer)]

> possibly not so complicated -- what about the following patch:
> diff --git a/dix/getevents.c b/dix/getevents.c
> index 2fd4e54..79366f8 100644
> --- a/dix/getevents.c
> +++ b/dix/getevents.c
> @@ -414,6 +414,10 @@ GetKeyboardValuatorEvents(xEvent *events, DeviceIntPtr
> pDev, int type,
> CARD32 ms = 0;
> deviceKeyButtonPointer *kbp = NULL;
>
> + if (pDev == inputInfo.keyboard)
> + pDev = dixLookupPrivate(&inputInfo.keyboard->devPrivates,
> + CoreDevicePrivateKey);
> +
> if (!events)
> return 0;
>
>
> (assuming all callers of GK{,V}E are happy with this.)

won't work, ProcXTestFakeInput doesn't use GPE/GKVE right now. I have a patch
for master in the pipe here, but it still needs some special handling for
xinerama. once it is in, it can probably be backported to 1.4.

[Peter Hutterer (peter-hutterer)]

I just pushed a fix to master [1] that fixes this issue. Unfortunately it turned
out rather invasive, so it needs active backporting to 1.4.

The main part is to switch ProcXTestFakeInput to use GPE/GKVE, and flip the
device to the last-used slave device.

[1] 105d28652d1fb80dd8ce8511e2605dccc8812e99

[Brice Goglin (brice-goglin)]

Is all this related to bug#15359 and bug#9964 ? I am having a hard time trying to sort out all our LED-related bugs.

[Peter Hutterer (peter-hutterer)]

> --- Comment #15 from Brice Goglin <email address hidden> 2008-06-21 11:16:22 PST ---
> Is all this related to bug#15359 and bug#9964 ? I am having a hard time trying
> to sort out all our LED-related bugs.

I don't think so. This bug is a special case as it modifies the state of the
VCP without going through the physical device (using XTest).
#15359 and #9964 are caused by wrong processing of the device.

[Jan Vlnas (jnv)]

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

[Martin-Éric Racine (q-funk)]

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

[cprise (cprise-yahoo)]

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.

[Jan Vlnas (jnv)]

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).

[Mauricio (mruibal)]

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!!!

[Pierre (pdm4)]

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.

[Shushan Wen (shushanwen)]

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.

[Jordan Erickson (lns)]

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!

[James Dunmore (james-dunmore)]

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.

[Sndirsch-suse (sndirsch-suse)]

CLosing as fixed.

[Rolf Leggewie (r0lf)]

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?

[M. Nease (mlnease-hctc)]

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

Thanks, Cipher_no1.

mike

[Pronoique (pronoiaque)]

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

async between leds status and real numlock status.

[Rolf Leggewie (r0lf)]

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

[Scott Brown (scotty-b-brown)]

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....

[Vish (vish)]

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.

[Rolf Leggewie (r0lf)]

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

[Vish (vish)]

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

[Rolf Leggewie (r0lf)]

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.

[Vish (vish)]

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.

[winux (g-vaquant)]

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

[M. Nease (mlnease-hctc)]

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

[Rolf Leggewie (r0lf)]

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.

[Martin-Éric Racine (q-funk)]

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.

[Vish (vish)]

@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]

[Rolf Leggewie (r0lf)]

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.

[Rolf Leggewie (r0lf)]

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?

[Vish (vish)]

@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.

[Coren (coren+)]

Hi *,

It seems it's broken again on current 7.5 version. If you take and launch the sample program (CapsLockToggle.c), it won't light the LED as it should.

Can someone please re-open the bug ?

Thanks,

[Jeromeg (jeromeg)]

I can confirm Michel Loiseleur's comment, the original issue is present again with 7.5. I'm reopening the bug.

Thanks!

[NL_Derek (dff)]

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

[NL_Derek (dff)]

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

[Janet (bugzilla-kerridis)]

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.

[Sndirsch-suse (sndirsch-suse)]

I can confirm that the behaviour is broken again (LED doesn't lighten up/down) with xorg-server 1.9.0 when running the CapsLockToggle sample.

[Sndirsch-suse (sndirsch-suse)]

numlockx works as expected (including LED status) on xorg-server 1.9.0.

[Dimitri Bakalow (dimitri-bakalow)]

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.

[Peter Hutterer (peter-hutterer)]

right, so this situation is actually quite complicated.

First - any XTEST event will be executed on the virtual XTEST device, which will have the LED on. Being virtual, that's of limited use. Since the same event travels through the matching master device (virtual core keyboard (VCK), in most cases), this one will also have the LED on. Of limited, use, it's virtual too.

Using XTEST to switch a physical keyboard's LEDs on or off becomes complicated because each keyboard may have different indicators (and modifiers, etc.) so it's not clear-cut which indicators to switch on or off and under which conditions to do so. Furthermore, because we handle keyboards separately (and the event handling is quite frankly a disaster) there is a disconnect between the actual keyboard devices and the merged master device, the VCK. Hitting CapsLock on a physical keyboard will set the lock on this keyboard and thus on the master device. Sending a CapsLock through XTEST will set CapsLock on the XTEST device but unlock it on the merged device. So now you have two keyboard devices with CapsLock on, but the master device has it off. For indicators, the same is true of course.

I have yet to find a correct solution for the server to handle this case, especially when there are multiple keyboard layouts present. However, there's a simple solution for clients to deal with this: send XTEST events through the matching physical device that forced the CapsLock on. This will unset CapsLock on the physical keyboard and thus also extinguish the LED.

[luvr (luc-vanrompaey)]

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.

[Andreas Metzler (k-launchpad-downhill-at-eu-org)]

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

[Tiedemate (bjoerntiedemann)]

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

[Alejandro Moreno Calvo (almorca)]

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

[Paul White (paulw2u)]

Also seeing this problem in Natty

[Bryce Harrington (bryce)]

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

[Rolf Leggewie (r0lf)]

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.

[s0undt3ch (ufs)]

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

[Launchpad Janitor (janitor)]

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

[Freedesktop-zen-ssokolow (freedesktop-zen-ssokolow)]

(In reply to comment #22)
> Using XTEST to switch a physical keyboard's LEDs on or off becomes
> complicated because each keyboard may have different indicators (and
> modifiers, etc.) so it's not clear-cut which indicators to switch on or off
> and under which conditions to do so. Furthermore, because we handle
> keyboards separately (and the event handling is quite frankly a disaster)
> there is a disconnect between the actual keyboard devices and the merged
> master device, the VCK. Hitting CapsLock on a physical keyboard will set the
> lock on this keyboard and thus on the master device. Sending a CapsLock
> through XTEST will set CapsLock on the XTEST device but unlock it on the
> merged device. So now you have two keyboard devices with CapsLock on, but
> the master device has it off. For indicators, the same is true of course.

You have my sincere thanks. Now that I finally know what causes the LED to go out of sync, I can trigger it intentionally by running this on login:

numlockx off; xdotool key Num_Lock

I still don't know how to break the modifier state and the LED apart so I can flash the LED to indicate something like unread mail (see Bug 49276), but at least it can warn me if I accidentally disable NumLock (which I only do intentionally in certain games), rather than requiring me to put a piece of tape over it.

(My keyboard is a Rosewill RK-9000I. The LED is one of those ultra-bright, water-clear lens'd blue ones meant more for illumination than use as indicators and the surrounding plastic is white as snow. It'd be bothersome to find pure white electrical tape, ugly to apply enough layers to block the LED, and I don't want void the warranty by desoldering it.)

[Chris Rainey (ckrzen)]

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.

[Chris Rainey (ckrzen)]

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.

[Chris Rainey (ckrzen)]

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