Bug 1029805 - NumLock LED after suspend is off even though the NumLock is on
Summary: NumLock LED after suspend is off even though the NumLock is on
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon
Version: 19
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-13 09:23 UTC by Petr Kočandrle
Modified: 2015-02-18 11:00 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1047921 1056571 (view as bug list)
Environment:
Last Closed: 2015-02-18 11:00:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 722753 0 None None None Never

Description Petr Kočandrle 2013-11-13 09:23:36 UTC
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.

Comment 1 Petr Kočandrle 2013-11-13 09:24:44 UTC
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.

Comment 2 Petr Kočandrle 2013-11-14 08:09:57 UTC
I've updated some packages and the suspend/resume use-case now works ok. But the disconnect/reconnect still doesn't.

Comment 3 Jaromír Cápík 2014-01-02 13:31:21 UTC
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.

Comment 4 Jaromír Cápík 2014-01-02 14:24:21 UTC
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 ?

Comment 5 Jaromír Cápík 2014-01-02 15:01:06 UTC
It seems the problem lies in the evdev driver ...

https://bugs.freedesktop.org/show_bug.cgi?id=8411

Comment 6 Jaromír Cápík 2014-01-02 15:15:51 UTC
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

Comment 7 Jaromír Cápík 2014-01-02 15:36:13 UTC
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)

Comment 8 Jaromír Cápík 2014-01-02 15:42:52 UTC
Upgrade to 2.8.2 does NOT resolve the issue.

Comment 9 Jaromír Cápík 2014-01-03 12:06:26 UTC
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 ...

Comment 10 Jaromír Cápík 2014-01-03 12:16:35 UTC
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.

Comment 11 Peter Hutterer 2014-01-06 07:55:00 UTC
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).

Comment 12 Jaromír Cápík 2014-01-06 10:25:35 UTC
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.

Comment 13 Jaromír Cápík 2014-01-06 10:45:54 UTC
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.

Comment 14 Jaromír Cápík 2014-01-06 12:19:04 UTC
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.

Comment 15 Peter Hutterer 2014-01-08 10:16:16 UTC
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?

Comment 16 Jaromír Cápík 2014-01-08 12:55:12 UTC
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.

Comment 17 Tomáš Bžatek 2014-01-08 14:08:58 UTC
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.

Comment 18 Peter Hutterer 2014-01-09 06:52:40 UTC
(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.

Comment 19 Jaromír Cápík 2014-01-09 14:29:55 UTC
(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.

Comment 20 Peter Hutterer 2014-01-16 06:42:13 UTC
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.

Comment 21 Fedora End Of Life 2015-01-09 22:22:02 UTC
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.

Comment 22 Fedora End Of Life 2015-02-18 11:00:10 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.