Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
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) [edit] xorg.conf My xorg.conf, happens to me too.
Created an attachment (id=130675) [edit] 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) [edit] xorg.conf Happens to me too.
Created an attachment (id=130830) [edit] 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) [edit] xorg.conf of x86 arch
Created an attachment (id=131322) [edit] 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) [edit] 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) [edit] 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. ***
(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.
