Note: this bug is for the 7.3 release (for which no entry in Bugzilla exists yet). After upgrading X to 7.3 and xkeyboard-config to the latest version, the keyboard leds stopped responding to the caps lock, scroll lock, and num lock modifiers. The scroll lock modifier CAN be changed through xset. This happens even after doing setxkbmap -layout us -option "" There is no XLeds entry in my xorg.conf. I'm using a normal PS/2 keyboard, using the kbd driver.
The same. Do developers need some additional information?
*** Bug 12483 has been marked as a duplicate of this bug. ***
I have the same problem, only I am using an evdev device as my CoreKeyboard. The keyboard itself works fine, but I get no LEDs. Furthermore, I put a bit of debug output into the evdev input driver and did not ever see EvdevKbdCtrl get called when I toggle capslock, numlock, or scrolllock.
Created attachment 11650 [details] XOrg.conf Seems like a general problem. Here's the list of installed, x11 related packages on my system: x11-apps/bdftopcf-1.0.0 x11-apps/iceauth-1.0.2 x11-apps/luit-1.0.2 x11-apps/mesa-progs-7.0.1 x11-apps/mkfontdir-1.0.3 x11-apps/mkfontscale-1.0.3 x11-apps/rgb-1.0.1 x11-apps/setxkbmap-1.0.4 x11-apps/xauth-1.0.2 x11-apps/xclock-1.0.3 x11-apps/xdpyinfo-1.0.2 x11-apps/xev-1.0.2 x11-apps/xhost-1.0.2 x11-apps/xinit-1.0.5-r1 x11-apps/xkbcomp-1.0.3 x11-apps/xmessage-1.0.2 x11-apps/xprop-1.0.3 x11-apps/xrandr-1.2.2 x11-apps/xrdb-1.0.4 x11-apps/xset-1.0.3 x11-apps/xsetroot-1.0.2 x11-apps/xsm-1.0.1 x11-base/xorg-server-1.4-r1 x11-drivers/nvidia-drivers-100.14.19 x11-drivers/xf86-input-evdev-1.1.5-r1 x11-libs/libICE-1.0.4 x11-libs/libSM-1.0.3 x11-libs/libX11-1.1.3 x11-libs/libXau-1.0.3 x11-libs/libXaw-1.0.4 x11-libs/libXcomposite-0.4.0 x11-libs/libXcursor-1.1.9 x11-libs/libXdamage-1.1.1 x11-libs/libXdmcp-1.0.2 x11-libs/libXext-1.0.3 x11-libs/libXfixes-4.0.3 x11-libs/libXfont-1.3.1 x11-libs/libXfontcache-1.0.4 x11-libs/libXft-2.1.12 x11-libs/libXi-1.1.3 x11-libs/libXinerama-1.0.2 x11-libs/libXmu-1.0.3 x11-libs/libXp-1.0.0 x11-libs/libXpm-3.5.7 x11-libs/libXrandr-1.2.2 x11-libs/libXrender-0.9.4 x11-libs/libXres-1.0.3 x11-libs/libXt-1.0.5 x11-libs/libXtst-1.0.3 x11-libs/libXv-1.0.3 x11-libs/libXvMC-1.0.4 x11-libs/libXxf86misc-1.0.1 x11-libs/libXxf86vm-1.0.1 x11-libs/libdrm-2.3.0 x11-libs/libfontenc-1.0.4 x11-libs/liblbxutil-1.0.1 x11-libs/libnotify-0.4.4 x11-libs/libsexy-0.1.11 x11-libs/libwnck-2.18.3 x11-libs/libxcb-1.0 x11-libs/libxkbfile-1.0.4 x11-libs/libxkbui-1.0.2 x11-libs/pixman-0.9.5 x11-libs/xcb-util-0.2 x11-libs/xtrans-1.0.4 x11-misc/gccmakedep-1.0.2 x11-misc/icon-naming-utils-0.8.2-r1 x11-misc/imake-1.0.2 x11-misc/makedepend-1.0.1 x11-misc/read-edid-1.4.1-r1 x11-misc/shared-mime-info-0.22 x11-misc/slim-1.3.0 x11-misc/util-macros-1.1.5 x11-misc/xbitmaps-1.0.1 x11-misc/xdg-utils-1.0.2 x11-misc/xkeyboard-config-0.9 x11-misc/xorg-cf-files-1.0.2 x11-proto/bigreqsproto-1.0.2 x11-proto/compositeproto-0.4 x11-proto/damageproto-1.1.0 x11-proto/evieext-1.0.2 x11-proto/fixesproto-4.0 x11-proto/fontcacheproto-0.1.2 x11-proto/fontsproto-2.0.2 x11-proto/glproto-1.4.8 x11-proto/inputproto-1.4.2.1 x11-proto/kbproto-1.0.3 x11-proto/printproto-1.0.3 x11-proto/randrproto-1.2.1 x11-proto/recordproto-1.13.2 x11-proto/renderproto-0.9.3 x11-proto/resourceproto-1.0.2 x11-proto/scrnsaverproto-1.1.0 x11-proto/trapproto-3.4.3 x11-proto/videoproto-2.2.2 x11-proto/xcb-proto-1.0 x11-proto/xcmiscproto-1.1.2 x11-proto/xextproto-7.0.2 x11-proto/xf86bigfontproto-1.1.2 x11-proto/xf86dgaproto-2.0.3 x11-proto/xf86driproto-2.0.3 x11-proto/xf86miscproto-0.9.2 x11-proto/xf86rushproto-1.1.2 x11-proto/xf86vidmodeproto-2.2.2 x11-proto/xineramaproto-1.1.2 x11-proto/xproto-7.0.10 Portage 2.1.3.9 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22-gentoo-r6 x86_64) ================================================================= System uname: 2.6.22-gentoo-r6 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ Timestamp of tree: Wed, 19 Sep 2007 08:50:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.5.1-r2 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0_rc4-r1 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18 sys-devel/gcc-config: 1.4.0-r2 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2
I have Gentoo (~amd64 with Core 2 Duo) also, and to be sure it isn't some kind of installation/upgrade problem, I have reemerged the whole system from "empty tree" (emerge -e system; emerge -e world)... and have got the same issue with leds.
This problem is known upstream and wasn't considered a blocker bug, it will most likely be fixed in a minor version release of the xserver (1.4.1 iirc).
Sorry if i caused confusion, i thought this was gentoo bugzilla.
Same here for i686 Arch Linux and PS/2 keyboard. Any patches?
Just out of curiosity, can you also reproduce #12509 (another keyboard bug)? For me both broke at the same time, so perhaps they are related.
I don't have any patches, sorry.
Leds are not working for me either, and some combinations mentioned in bug #12509 return lower case instead of upper case for me too. This led bug has bitten many, how can it be that nobody seems to know where the problem comes from?
That this turns out to be the cause of #12509 is interesting. Reverting commit 8e5102 may help this. The patches to fix this are relatively complex (being that they touch some terrifyingly underdocumented pieces of code), and may well break other things, so they're going on to their own branch before it hits 1.4.1. I hope to push this next week.
In xf86-input-keyboard/src/kbd.c http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-keyboard.git;a=blob;h=c1daa4b6e86c479f40057f763b76e8afed590b80;hb=95e5d2521fc39a661e13b313e5aa2514ddac9a5e;f=src/kbd.c line 680 if (pKbd->noXkb) { I believe it should be: if (!pKbd->noXkb) { With that change, after compiling, my leds are now working.
(In reply to comment #13) However, while it does "fix" part of the leds problem, if I keep turning the caps lock on and off very fast while typing something, there are times that the led will remain off but the keyboard will write like if it was on (you only need to press the caps lock button once again to fix it). So the code for the autorepeater isn't working that well, but it works very well if you're not a troll :)
(In reply to comment #13) > I believe it should be: > > if (!pKbd->noXkb) { > > With that change, after compiling, my leds are now working. Bruno, yes, it works for me also. But things like below - doesn't do: Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll"
That only papers over the issue. I'm hoping to push a 1.4 branch with the real fixes very soon.
Modifying xf86-input-keyboard-1.2.2/src/kbd.c is an option, but the wrong solution, as it will handle the leds as if the kxb extension were disabled, i.e. like starting an Xserver compiled with -DXKB but with the option -kb to disable the XKB extension, and it may cause undesirable side effects (probably not as it will just update the leds as they are pressed, instead of requiring xkb to parse the keyboard state). A possible better solution (at least it should be correct "semantically") would be change the Xserver: -%<- --- xorg-server-1.4/dix/devices.c.orig 2007-10-19 17:04:51.000000000 -0200 +++ xorg-server-1.4/dix/devices.c 2007-10-23 17:50:38.000000000 -0200 @@ -294,7 +294,17 @@ CoreKeyboardBell(int volume, DeviceIntPt static void CoreKeyboardCtl(DeviceIntPtr pDev, KeybdCtrl *ctrl) { +#ifdef XKB + if (!noXkbExtension) { + DeviceIntPtr dev = (DeviceIntPtr) + pDev->devPrivates[CoreDevicePrivatesIndex].ptr; + + if (dev && dev->key && dev->key->xkbInfo && dev->key->xkbInfo->kbdProc) + (*dev->key->xkbInfo->kbdProc)(dev, ctrl); + } +#else return; +#endif } /** -%<- Or update the pointer in the xkbInfo of the "virtual core keyboard" as another option, but probably uglier :-) I did not yet investigate it very well, but there is also some problem related to Scroll Lock, that with the above patch doesn't still work properly.
The problem is that it ignores the XKB indicator mappings. The core control solution is a little closer, but this also ignores the unified keyboard state, and only sets it on one device. It's a perfectly fine patch to put in distributions for the time being though, so, thanks.
Sorry for not understanding very well the new input code. Do you mean a better solution would be to traverse the inputInfo.devices calling the proper KbdCtrl function, to update leds? That would make sense, I believe, and then, the fact that it calling the "virtual" CoreKeyboardCtl is the correct behaviour (I was thinking it could be a bug). I was even considering to update pointers in dix/events.c:SwitchCoreKeyboard(), but did not do that because it would make things even harder to understand, and could require special cleanup code, etc.
(In reply to comment #17) > A possible better solution (at least it should be correct "semantically") > would be change the Xserver: > ... Have tried - it works for me (Gentoo/~amd64), thanks!
FYI, with the code on the current git server-1.4-branch (as of today, last commit is 007e2239cf65...): - Capslock works - Numlock turns on/off, but the logic is inverted - Scrolllock doesn't work at all I'm on Linux, using the latest evdev driver (xserver ignores my xorg.conf settings and defaults to evdev, AFAIK). My keyboard is a PS2 Logitech Access Keyboard. I can reproduce it using a Mtek generic PS2 keyboard as well.
with xorg-server v.1.4.0.90 (on Gentoo ~amd64) all works fine for me.
In what version is the fix? I use 1.4.0.90 (Debian xserver-xorg 1:7.3+10) and, while CapsLock and NumLock leds work, trying to use the ScrollLock led as a group indicator doesn't. xkb_compatibility { include "default" include "ledscroll(group_lock)" }; And in group_lock (part of xkb-data package): partial xkb_compatibility "group_lock" { indicator "Scroll Lock" { modifiers= None; groups=All-group1; }; }; The led is always off, no matter which group is active. "xkbvleds +real" shows me three leds that are supposed to match the three physical leds on my keyboard, and all three, including ScrollLock, act as expected, i.e. the one representing ScrollLock actually reflects the active group. It's only that the physical led doesn't light up when it should. The keyboard driver is kbd, here is my whole keymap file: xkb_keymap { xkb_keycodes { include "xfree86" }; xkb_types { include "default" }; xkb_compatibility { include "default" include "ledscroll(group_lock)" }; xkb_symbols { include "pc(pc105)" include "x-no" include "x-ru:2" include "group(ctrl_shift_toggle)" replace "symmetric" }; xkb_geometry { include "pc(pc104)" }; }; I have the same problem both on the desktop and laptop.
This issue seems to be fixed in master.
Can you please point our a particular commit that fixes it (for backporting)?
> --- Comment #25 from Alexey Feldgendler <alexey@feldgendler.ru> 2008-08-07 01:13:59 PST --- > Can you please point our a particular commit that fixes it (for backporting)? unfortunately no, I just tried it with master and it worked fine. tracking down the commit could be tricky, simply due to the number of commits since.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.