Bug 12434

Summary: Keyboard leds don't reflect modifier state
Product: xorg Reporter: Serge van den Boom <svdb+freedesktop.org>
Component: Input/KeyboardAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: high CC: ademar, ajax, alexey, andrew.james.barr, anssi, brebs, chris, colin, dberkholz, ghepeu, i.am, jcristau, jm, matt, me, mrmazda, pcpa, pmlists, roman, rw, safari-ml-freedesktop-bugzilla-kv7oy2vp4mc4jvudr6vccb7oetrzzqe7fwnhahno, shrek, sliedes, snelius, wouter-freedesktop
Version: 7.3 (2007.09)   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
XOrg.conf none

Description Serge van den Boom 2007-09-15 06:35:07 UTC
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.
Comment 1 anli 2007-09-17 03:56:55 UTC
The same.
Do developers need some additional information?
Comment 2 Peter Hutterer 2007-09-19 04:58:39 UTC
*** Bug 12483 has been marked as a duplicate of this bug. ***
Comment 3 Jim Ramsay 2007-09-19 08:19:01 UTC
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.
Comment 4 Dennis Schridde 2007-09-19 17:11:57 UTC
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
Comment 5 anli 2007-09-19 23:37:15 UTC
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.
Comment 6 Maarten Maathuis 2007-09-29 12:55:08 UTC
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).
Comment 7 Maarten Maathuis 2007-09-29 13:05:17 UTC
Sorry if i caused confusion, i thought this was gentoo bugzilla.
Comment 8 Rafał Bilski 2007-10-04 02:48:36 UTC
Same here for i686 Arch Linux and PS/2 keyboard. Any patches?
Comment 9 Sami Liedes 2007-10-10 03:17:44 UTC
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.
Comment 10 Daniel Stone 2007-10-10 03:42:44 UTC
I don't have any patches, sorry.
Comment 11 Wouter Van Hemel 2007-10-10 17:09:48 UTC
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?
Comment 12 Daniel Stone 2007-10-11 01:11:46 UTC
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.
Comment 13 Bruno Laturner Lemes 2007-10-18 20:47:57 UTC
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.
Comment 14 Bruno Laturner Lemes 2007-10-18 21:01:59 UTC
(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 :)
Comment 15 anli 2007-10-18 21:24:44 UTC
(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"
Comment 16 Daniel Stone 2007-10-19 00:01:44 UTC
That only papers over the issue.  I'm hoping to push a 1.4 branch with the real fixes very soon.
Comment 17 Paulo César Pereira de Andrade 2007-10-23 16:43:25 UTC
  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.
Comment 18 Daniel Stone 2007-10-23 16:57:55 UTC
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.
Comment 19 Paulo César Pereira de Andrade 2007-10-23 17:26:12 UTC
  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.
Comment 20 anli 2007-10-23 17:29:01 UTC
(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!
Comment 21 Ademar Reis 2007-11-13 07:19:38 UTC
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.
Comment 22 anli 2007-12-14 05:45:06 UTC
with xorg-server v.1.4.0.90 (on Gentoo ~amd64) all works fine for me.
Comment 23 Alexey Feldgendler 2008-06-22 09:07:14 UTC
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.
Comment 24 Peter Hutterer 2008-08-06 19:53:38 UTC
This issue seems to be fixed in master.
Comment 25 Alexey Feldgendler 2008-08-07 01:13:59 UTC
Can you please point our a particular commit that fixes it (for backporting)?
Comment 26 Peter Hutterer 2008-08-08 00:05:29 UTC
> --- 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.
Comment 27 Adam Jackson 2018-06-12 19:07:27 UTC
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.