Description of problem: When I turn on NumLock the LED is switched on, then I suspend and resume the computer, the NumLock is still on and the LED is off. When I hit NumLock key, the NumLock turn off, but the LED turns on, so it is indicating the opposite status to the real one. The same problem happens when I disconnect the keyboard from USB port with NumLock turned on and then reconnect it. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg.x86_64 1.14.3-2.fc19 xorg-x11-xkb-utils.x86_64 7.7-7.fc19 gnome-shell.x86_64 3.8.4-2.fc19 gnome-settings-daemon.x86_64 3.8.5-1.fc19 How reproducible: Everytime. Steps to Reproduce: 1. Turn on the NumLock 2. Suspend & Resume 3. Check the NumLock LED Actual results: The NumLock LED shows the opposite to the actual NumLock status after suspend with NumLock turned on. Expected results: The NumLock status LED shows the actual status of NumLock function. Additional info: It happens to my Thinkpad with external keyboard connected. Maybe systems with one keyboard only work ok, haven't checked that.
Not sure about the component, but since it happens in Gnome, I filled gnome-shell in. Feel free to change it to anything that fits better.
I've updated some packages and the suspend/resume use-case now works ok. But the disconnect/reconnect still doesn't.
Hi. The same happens in xfce4 on my desktop PC with USB keyboard (I think I didn't experience that with PS2 keyboards, but this needs to be re-checked). When I switch to the console with CTRL+ALT+Fx, then the behaviour is OK, when I switch back to the X, the behavior becomes wrong again ... To workaround the issue I have to turn the Num Lock Off (so that the LED is On) and then disconnect and reconnect the keyboard. The issue also appears when an unwanted USB controller reset appears (kernel problem) and consequently the LED behaviour inverts several times per day ... Regards, Jaromir.
I just tested the same on a different computer and it worked correctly. It seems the LEDs are not correctly driven/refreshed in my case. I tested two keyboards plugged in at the same time and whilst on the 'working' computer the LEDs get refreshed on both keyboards when I press the NumLock on any of them, the same doesn't happen on my workstation. Is there any daemon that drives the LEDs in X ?
It seems the problem lies in the evdev driver ... https://bugs.freedesktop.org/show_bug.cgi?id=8411
The issue is not reproducible on Gentoo with the following components/settings... [ 10539.047] (II) config/udev: Adding input device Dell Dell USB Keyboard (/dev/input/event3) [ 10539.047] (**) Dell Dell USB Keyboard: Applying InputClass "evdev keyboard catchall" [ 10539.047] (II) Using input driver 'evdev' for 'Dell Dell USB Keyboard' [ 10539.047] (**) Dell Dell USB Keyboard: always reports core events [ 10539.047] (**) evdev: Dell Dell USB Keyboard: Device: "/dev/input/event3" [ 10539.047] (--) evdev: Dell Dell USB Keyboard: Vendor 0x413c Product 0x2003 [ 10539.047] (--) evdev: Dell Dell USB Keyboard: Found keys [ 10539.047] (II) evdev: Dell Dell USB Keyboard: Configuring as keyboard [ 10539.047] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1.2/3-1.2:1.0/input/input6/event3" [ 10539.047] (II) XINPUT: Adding extended input device "Dell Dell USB Keyboard" (type: KEYBOARD, id 9) [ 10539.047] (**) Option "xkb_rules" "evdev" [ 10539.047] (**) Option "xkb_model" "pc104" [ 10539.047] (**) Option "xkb_layout" "us" x11-base/xorg-server-1.14.3-r2 x11-drivers/xf86-input-evdev-2.8.1 a jinak kernel 3.11.5-zen-gdccb7cf-dirty tak nejak napolo vlastni vyroby x11-libs/libXi-1.7.2
The following commits probably explain a lot ... commit 51575b60b14d414490d31ff23f07c30431525667 Author: Peter Hutterer <peter.hutterer> Date: Mon Oct 7 09:23:09 2013 +1100 evdev 2.8.2 .... Signed-off-by: Peter Hutterer <peter.hutterer> commit f285567d372514d31096cc25a467d5d2e182885a Author: Peter Hutterer <peter.hutterer> Date: Tue Aug 13 14:44:26 2013 +1000 Write a SYN_REPORT after the last LED .... When writing LED values to the device, append a SYN_REPORT to the list to ensure other clients are updated immediately. Otherwise, the LED events will be queued and not sent to other clients until the next input event arrives. .... Signed-off-by: Peter Hutterer <peter.hutterer> Reviewed-by: Daniel Stone <daniel> (cherry picked from commit 27926b3763e525470ec8e4ac9a97aa0e02f1dd95)
Upgrade to 2.8.2 does NOT resolve the issue.
The following command changes the behavior under X in Linux Mint 16 (Ubuntu based) so that the LEDs get at least updated on both USB keyboards (even when they still can be inverted) sudo kbd_mode -u Going to test that with Fedora ...
When testing in Mint with one keyboard only ... after plugging the keyboard in the NumLock LED is turned On for a second and then turned Off again. It looks like some conflict of two or more processes trying to drive the LEDs or clearing the LED status by doing some initialization ... really don't know, just guessing.
I can reproduce the bug here. Plugging a USB keyboard in, switching numlock on, unplugging/replugging the keyboard, numlock is enabled but the LED is off. (In reply to Jaromír Cápík from comment #6) > x11-base/xorg-server-1.14.3-r2 > x11-drivers/xf86-input-evdev-2.8.1 > a jinak kernel 3.11.5-zen-gdccb7cf-dirty tak nejak napolo vlastni vyroby > x11-libs/libXi-1.7.2 this list unfortunately doesn't help much, I'd need to know the desktop environment that was running there too and whether it works without a desktop environment. GNOME has a setting to save numlock status, it may have applied it here. I can't imagine the server having worked correctly in this regard for several server versions (indeed, I tested 1.14.3 and 1.14.2 and both are buggy).
As far as I remember it was Gnome 2 ... I'm CCing Tomas Bzatek, who owns the Gentoo machine, maybe he could do some tests and tell you more.
I remember I experienced very first troubles with the NumLock LED approximately 2 years ago, but the problem varied on different distros and I admit I should report that immediately. However I'd like to focus on the problem resolution right now as it's pretty annoying. Don't hesitate to ask me for additional debug data. I have access to several different computers with different Linux/Unix distributions.
I'm unable to reproduce the issue on my several years old and not updated Gentoo, but as it says "error loading evdev" I guess it still uses the kbd driver. Don't know if this info is relevant and helpful. I can also confirm, the issue affects USB keyboards only.
It looks like the reason this works on the old machines (and RHEL6 btw) is that gnome 2 would trigger the LEDs for new devices. Testing this on a plain X server in RHEL6 still shows the problem, it doesn't happen once GNOME is running. Bastien pointed me to gsd-keyboard-manager.c:numlock_set_xkb_state() which triggers an LED update on newly plugged devices. Bastien, what's the chance of getting this or something like this for GNOME3?
Hi Peter. I want it in other sessions too as I'm primarily using Xfce session. In my old Gentoo it works correctly in Xfce, Fluxbox and plain X. We have to wait for Tomas Bzatek and his tests, since his Gentoo runs with evdev. I'd like to know the result. I'm curious why the LED behaviour changes for 2 USB keyboards with the 'sudo kbd_mode -u' command ... IMO the LEDs should be driven correctly regardless of external tools like gsd-keyboard-manager ... Regards, Jaromir.
Just tested with Jaromir on my machine (running vanilla Gnome 2.32), confirming this is a job of the keyboard g-s-d plugin. Deactivating it via /apps/gnome_settings_daemon/plugins/keyboard/active GConf key makes the LEDs act separately, not being synchronized.
(In reply to Jaromír Cápík from comment #16) > I'm curious why the LED behaviour changes for 2 USB > keyboards with the 'sudo kbd_mode -u' command the server switches to K_RAW mode for a reason, once you run kbd_mode -u the tty will interpret keystrokes in addition to X. just hit Alt+F2 after running kbd_mode -u. This is not a workaround. > ... IMO the LEDs should be > driven correctly regardless of external tools like gsd-keyboard-manager ... well, yes, I'm not disagreeing here. but fixing this correctly in X is rather a nightmare.
(In reply to Peter Hutterer from comment #18) > (In reply to Jaromír Cápík from comment #16) > > I'm curious why the LED behaviour changes for 2 USB > > keyboards with the 'sudo kbd_mode -u' command > > the server switches to K_RAW mode for a reason, once you run kbd_mode -u the > tty will interpret keystrokes in addition to X. just hit Alt+F2 after > running kbd_mode -u. This is not a workaround. I never wrote it is. It doesn't resolve the issue, it just changes the behaviour. > > > ... IMO the LEDs should be > > driven correctly regardless of external tools like gsd-keyboard-manager ... > > well, yes, I'm not disagreeing here. but fixing this correctly in X is > rather a nightmare. Once something good in principle becomes a nightmare, then it means it's a hot candidate for a huge redesign. I consider this a very basic feature and when we're unable to control such basic stuff, then we're lost.
going to reassign it to gnome-settings-daemon. That component used to make sure this works (it was always broken in the server). Upstream commit 34395459cc removed that call. I tentatively put it back in for testing and the LED lights up.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.