Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Since update of xorg-server, xorg-x11 and xf86-input-keyboard. Keyboard
indicator LEDs (Num Lock, Scroll Lock and Caps Lock) no longer work. No hint as
to why is given in xorg logs and I've tried rebuilding the driver. It's fine in
a terminal (ctrl+alt+F1) and it happens to both laptop keyboard and and
external USB one.

Reproducible: Always

Actual Results:  
Keyboard LEDs do not work

Expected Results:  
Keyboard LEDs work

Attach your xorg.conf

Created an attachment (id=130654) [details]
xorg.conf

My xorg.conf, happens to me too.

Created an attachment (id=130675) [details]
xorg.conf

xorg.conf as asked

Same problem here. But my NumLock works just fine. CapsLock and ScrollLock are
not working. This is on ~86 and ~amd64. I use ScrollLock led for keyboard
layout indication.

    Option "XKbOptions"  "grp:alt_shift_toggle,grp_led:scroll"

Created an attachment (id=130766) [details]
xorg.conf

Happens to me too.

Created an attachment (id=130830) [details]
xorg.conf

Same problem for me. Caps lock DO WORK but the led doesn't. Scroll lock and num
lock leds don't work too. I also use scroll lock as a grp_led and it is now
broken.

Also happens on x86.

Created an attachment (id=130996) [details]
xorg.conf of x86 arch

Created an attachment (id=131322) [details]
xorg.conf, ~amd64

Same here...

ditto
caps,num,scroll - keys work but leds do not when in X

Same here.

$ xsetleds -show
current states: CapsLock  off   NumLock off   ScrollLock off   
< HIT CAPS LOCK > or  $ xsetleds +caps
$ xsetleds -show
current states: CapsLock on   NumLock off   ScrollLock off  

But no led on/off. Anyway, that does not explain anything.

I downgrade to x11-base/xorg-server-1.3.0.0 and
x11-drivers/xf86-input-keyboard-1.1.1 and leds started working.

Problem is not specific for xf86-input-keyboard driver -  I switched to evdev
keyboard driver and leds still don't work.

This also occurs on FreeBSD, so it's not OS specific either.

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

http://lists.freedesktop.org/archives/xorg/2007-September/028562.html has some
info about this and says it will be fixed in xorg-server 1.4.1. There's a hacky
patch in the previous post. Since it's a known issue upstream, I'm going to
close as such.

Quote from that email

> This patch is pretty screwy: Peter Hutterer has the correct fix (making
> XKB properly deal with extended events), which we'll push for 1.4.1.

If the fix is already made, why can we not patch our ebuilds accordingly?

(In reply to comment #17)
> If the fix is already made, why can we not patch our ebuilds accordingly?

+1, but I found only that screwy patch (it doesn't even work correctly). I
tried to look after it in here: gitweb.freedesktop.org and I found nothing.
Maybe they've got a patch, but it hasn't been commited in git yet.

http://lists.freedesktop.org/archives/xorg/2007-September/028562.html has some
info about this and says it will be fixed in xorg-server 1.4.1. There's a hacky
patch in the previous post. Since it's a known issue upstream, I'm going to
close as such.(In reply to comment #17)
> Quote from that email
> 
> > This patch is pretty screwy: Peter Hutterer has the correct fix (making
> > XKB properly deal with extended events), which we'll push for 1.4.1.
> 
> If the fix is already made, why can we not patch our ebuilds accordingly?

Because I have no clue whether that correct fix exists now or is just a
concept, and I haven't seen a patch for it anywhere.

On 20:29 Sat 22 Sep     , Daniel Stone wrote:
> On Sat, Sep 22, 2007 at 04:54:56PM +0200, Brice Goglin wrote:
> > Is there an actual patch available somewhere? There are quite a lot of
> > users complaining about LEDs not working...
>
> Not yet; Peter's on the right track, but there's some more fixes we're
> going to need.  I'll be making an input-for-1.4.1 branch for this as it
> develops, starting next week.  Promise.
>
> Cheers,
> Daniel

*** Bug 194521 has been marked as a duplicate of this bug. ***

Created an attachment (id=134273) [details]
1.4-fix-kbdleds.patch

In the upstream bug there is now a patch available.

Daniel Stone says: "It's a perfectly fine patch to put in distributions for the
time being"

This patch should be added as 'files/1.4-fix-kbdleds.patch', and into
xorg-server-1.4-r2.ebuild in the 'PATCHES' section.  It works for me - My LEDs
work again!

I've tried this new patch and it behaves strange now. I just start KDE, turn on
the numlock so I can type the password, KDE starts and light go off (numlock
still on, though). I've pressed the numlock button and it just blinked and went
off again, so I tried it one more time and the light finally turned on (but
numlock was off)... so I had to fix it manually with xsetleds +num. After this
horror scene it seems to work OK (I mean switching between VTs with Xorg server
- it keeps settings).

Man... just ignore me, I've got xf86-input-keyboard still compiled with that
old messy patch.

(In reply to comment #22)
I can confirm that the patch works.  The LEDs behave as usual again.

Created an attachment (id=134445) [details]
ebuild diff to apply posted patch placed in $FILESDIR

confirmed that patch works here as well

*** Bug 197662 has been marked as a duplicate of this bug. ***

Reopening so it doesn't get lost in the next revbump of xorg-server.

What's the state of this bug?
If the patch works, why isn't there a new revision released?

1.4.1 is supposed to be released in a matter of a couple days.

So  let  me  try  to  understand  ,  the  current  xorg-server 1.4-r2  has  the
 patch  included?  Will  it  emerge  normally  and  work  or  do  I  need  to 
add  the  patch  myself?

xorg-server 1.4-r2 is still broken

Understood,  the  ebuild  in  the  portage  tree  is  still  broken  but  the 
patch  above  does  work,  whats  needed  is  to  manually  adjust  the  ebuild
 with  the  new  patch  and  emerge it.  

I  have  done  so  and  can  also  confirm  that  this  solves  the led 
problems.

Maybe I'll add the patch, since it seems 1.4.1 can't seem to make anywhere near
its projected release date.

Works for me on amd64 with 1.4.0-r2 and a generic Keytronic USB keyboard.  At
least, CapsLock and NumLock are both working correctly now...

Patch  should  be  added  to  ebuild  in  portage  tree,  it  compiles 
perfectly  and  since  yesterday,  no  glitches  whatsoever.

Billy,
  I do not see the patch added to portage tree. I still have only 1.4-r2
available which does not fix the problem. Thanks.

(In reply to comment #23)
> I've tried this new patch and it behaves strange now. I just start KDE, turn on
> the numlock so I can type the password, KDE starts and light go off (numlock
> still on, though). I've pressed the numlock button and it just blinked and went
> off again, so I tried it one more time and the light finally turned on (but
> numlock was off)... so I had to fix it manually with xsetleds +num. After this
> horror scene it seems to work OK (I mean switching between VTs with Xorg server
> - it keeps settings).
> 

I can confirm a similar behavior with
1.4-fix-kbdleds.pat1.4-fix-kbdleds.patchch on ~amd64. Activating caps-lock on
kdm login screen activates the caps lock and the LED. After logging in, caps
lock ist still activated but the LED turns of. Pressing caps lock one more
time, the key gets deactivated and the LED flashes short.  After next usage of
the caps lock key, the LED seems to work correctly under X11. 

Switching back to a console (F1-F6) then, deactivates both caps lock and LED on
the console. Switching back to X again activates both, key and LED.

(In reply to comment #38)
> I can confirm a similar behavior with
> 1.4-fix-kbdleds.pat1.4-fix-kbdleds.patchch on ~amd64. Activating caps-lock on
> kdm login screen activates the caps lock and the LED. After logging in, caps
> lock ist still activated but the LED turns of. Pressing caps lock one more
> time, the key gets deactivated and the LED flashes short.  After next usage of
> the caps lock key, the LED seems to work correctly under X11. 

+1

> Switching back to a console (F1-F6) then, deactivates both caps lock and LED on
> the console. Switching back to X again activates both, key and LED.

Well, every VT has its *lock settings, so if it's not active on VT1-6, it will
be deactivated...

Should be fixed in 1.4.0.90, please reopen if it's not.

*** Bug 202227 has been marked as a duplicate of this bug. ***

*** Bug 202227 has been marked as a duplicate of this bug. ***

*** Bug 202227 has been marked as a duplicate of this bug. ***

(In reply to comment #40)
> Should be fixed in 1.4.0.90, please reopen if it's not.
> 

Just installed 1.4.0.90 and indeed it does work. I believe this issue can be
considered resolved.