Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Something similar happens to me on a regular PC in the last weeks but it starts only after few minutes of work in X11, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465653 for details. PS2 keyboard works ok, USB keyboard suddenly freezes the LEDs state. Changing the state on still works, it's just not displayed. On the PS2 keyboard, it is displayed.

I was using kbd driver before, no evdev and there is still the same problem.

mass reassignment. Zephaniah isn't the maintainer anymore.

Can you please verify if this problem persists with evdev 2.1. Thanks.

Just tried again on the same machine, now running Linux 2.6.26 and evdev 2.1.0. The behaviour is closer to what I expected. Switching NumLock on and off works on both keyboards (almost) independently and the LEDs reflect the current state per keyboard.

There are two more issues:
1. When switching on NumLock on the integrated ThinkPad keyboard, the USB keyboard follows (behaviour and LED). Every other state change is independent.

2. The CapsLock key behaves very strange. The LEDs are updated independently and correctly. However, when activating CapsLock on one (let's call it keyboard A), both keyboards actually produce capital letters, except for the first letter typed on keyboard B. That is, every time I typed something on keyboard A, the next letter typed on B will be lowercase. Keyboard A gives only uppercase.

When activating CapsLock on both keyboard (order does not matter), they both capitalize every first letter typed, the rest is lowercase. By every first letter, again I mean after typing on the other keyboard.

On Sun, Dec 21, 2008 at 07:53:59AM -0800, bugzilla-daemon@freedesktop.org wrote:
> There are two more issues:
> 1. When switching on NumLock on the integrated ThinkPad keyboard, the USB
> keyboard follows (behaviour and LED). Every other state change is independent.

every other state change as in Alt, Ctrl, etc? or caps lock? Can you clarify
this please?

> 2. The CapsLock key behaves very strange. The LEDs are updated independently
> and correctly. However, when activating CapsLock on one (let's call it keyboard
> A), both keyboards actually produce capital letters, except for the first
> letter typed on keyboard B. That is, every time I typed something on keyboard
> A, the next letter typed on B will be lowercase. Keyboard A gives only
> uppercase.

> When activating CapsLock on both keyboard (order does not matter), they both
> capitalize every first letter typed, the rest is lowercase. By every first
> letter, again I mean after typing on the other keyboard.
 
Yeah, this is a know bug though I don't know if there's a bugreport for it.
Haven't found the time to look into yet yet, but any help is appreciated.
If you can't find a bugreport on this either please open a separate bug,
module Input/core and assign it to me.

I've exactly the same problem: Neither the NUMLOCK nor the CAPSLOCK leds light up when I press the corresponding keys, even though they most definitely work as expected. It is just the leds that are not updated.

Since I was unable to find any workaround or fix for this, is there anything I can do to help locate the problem?

evdev 2.8.2 w/ Xorg 1.15

I was looking for another bug on here and I found this. Funnily enough, I happen to have this bug on my computer using the xf86-input-evdev driver, and after finally getting annoyed with it I did some research into the issue. Hopefully this should clear up the actual cause of this bug.

It seems to come from the fact that for some strange reason, certain keyboards have multiple devices. Unfortunately, I don't know if it's the kernel creating the additional devices, or the device. I have a Nighthawk X7 mechanical keyboard on my desktop with this problem. When connected, Linux shows three different event nodes for it. One handles all of the standard keys from the keyboard, one handles some of the media keys, and the other handles the special macro keys (which ironically have their own key codes, probably with the assumption the operating system handles the macro part). Strangely, the event node that actually sends the key codes for the caps lock and number lock key is not the same one that handles the actual number lock and caps lock LEDs on the keyboard. Since all of these event nodes register as input devices with the xorg-server, and since Xorg (or the evdev driver, I haven't done the research to figure out which is responsible for this) has a separate caps/number lock state for each input device, the device with the LEDs that actually correspond to the real keyboard LEDs never get updated.

This being said, this isn't a bug that's present with all keyboards. I have a couple different USB keyboards that only create a single event node, and the LEDs on those keyboards work just fine.

As far as I'm aware this bug is still very much present in X, but I'll check when I get a chance to see if versions newer then 1.15 still have it.

Whoops, just realized I should clarify something in my last post. Keyboards do share the same caps lock state, but the LEDs are handled separately for each one.

Stumbled upon this bug when I was looking for something else. This was actually fixed sometime in 1.16 and hasn't been reproducible since.