Ever since the KBD extension came along the XLeds option to give LED control back has been broken. I think it must have been 10 years or so. Up until before Xorg-7.3 I could just turn the XKBD extension off, but 7.3 breaks the keyboard quite severely in that case (both "Keyboard" and "kbd" drivers, if they aren't the same anyway). I'll file the bugs around this later, but for now I'd like to discuss whether making XLeds working is something one can hope for. Maybe I misunderstand how LED control is supposed to work with xkbd and xleds. It's not that there is any documentation for programming APIs for the KBD extension out there, but XChangeKeyboardControl(3) and xset(1) sure don't work, except for LED number 3. Sorry for the sarcasm, but after 10 years, well :-) Here's another user reporting the same problem: http://lists.freedesktop.org/archives/xorg/2006-May/015490.html %% How to reproduce: - do not use Option "XkbDisable" so that you get the xkb extension - use 'Option "Xleds" "1 2 3"' - start X11 - commandline: `xset led 1` - commandline: `xset led 2` - commandline: `xset led 3` You'll see than only led 3 has been given back to XChangeKeyboardControl(3) control. Use XkbDisable and see how all leds work (careful in 7.3, you might have difficulties getting out of X11 since most other things break).
> Ever since the KBD extension came along the XLeds option to give LED control > back has been broken. I think it must have been 10 years or so. A quick grep on the xserver source shows that XLeds doesn't exist anymore anywhere but in some (deprecated) examples. > Up until before Xorg-7.3 I could just turn the XKBD extension off, but 7.3 > breaks the keyboard quite severely in that case (both "Keyboard" and "kbd" > drivers, if they aren't the same anyway). FYI, XKB will be mandatory in future versions of X. > You'll see than only led 3 has been given back to XChangeKeyboardControl(3) > control. This is correct according to section 9.2.1 of the XKB Protocol Spec: "If the IM_NoExplicit flag is set in an indicator map, attempts to change the state of the indicator are ignored." In most common layouts, leds 1 (caps) and 2 (numlock) are defined explicitly, scroll lock (led 3) isn't. removing the matching parts from the xkb description (or just the !allowExplicit) gives you full access to the LEDs. I'm marking this as NOTABUG, but it could also be WONTFIX. The XLeds option is not going to be resurrected.
XLeds is a driver specific option, supported by xf86-input-keyboard, but not xf86-input-evdev.
All right, two questions: Alan, how do I find out whether I run xf86-input-keyboard or xf86-input-evdev? In /proc/maps I only see b69d9000-b69e3000 r-xp 00000000 03:03 13975612 /usr/lib/xorg/modules/input/mouse_drv.so b7c11000-b7c16000 r-xp 00000000 03:03 13975611 /usr/lib/xorg/modules/input/kbd_drv.so Peter, where is that xkb description file? How do I find out which one I'm running?
(In reply to comment #2) > XLeds is a driver specific option, supported by xf86-input-keyboard, but > not xf86-input-evdev. Oh, you're right. I didn't think of grepping the drivers as well. My fault, sorry. Cancel my WONTFIX comment, it's just NOTABUG. (In reply to comment #3) > Alan, how do I find out whether I run xf86-input-keyboard or > xf86-input-evdev? Your Xorg.log should tell you. > Peter, where is that xkb description file? How do I find out which one I'm > running? you can get the currently loaded one by running xkbcomp -xkb :0 out.xkb it is generated by xkeyboard-config, when you specify a layout through setxkbmap or through the GUI tools.
(In reply to comment #4) > (In reply to comment #2) > > XLeds is a driver specific option, supported by xf86-input-keyboard, but > > not xf86-input-evdev. > > Oh, you're right. I didn't think of grepping the drivers as well. My fault, > sorry. > Cancel my WONTFIX comment, it's just NOTABUG. > > (In reply to comment #3) > > Alan, how do I find out whether I run xf86-input-keyboard or > > xf86-input-evdev? > > Your Xorg.log should tell you. No, it's only reporting the same .so files that I already got from /proc/.../maps Can you please tell me more specifically how to tell whether I run xf86-input-keyboard or xf86-input-evdev? > > Peter, where is that xkb description file? How do I find out which one I'm > > running? > > you can get the currently loaded one by running xkbcomp -xkb :0 out.xkb > it is generated by xkeyboard-config, when you specify a layout through > setxkbmap or through the GUI tools. So I guess I don't have a layout specified yet: $ xkbcomp -xkb :0 out.xkb Warning: Could not load keyboard geometry for :0 BadAlloc (insufficient resources for operation) Resulting keymap file will not describe geometry If I do not have a layout specified, what is the default that I have loaded? What can I use as a starting template to start making modifications?
> --- Comment #5 from Martin Cracauer <cracauer@cons.org> 2008-10-09 08:14:57 PST --- > Can you please tell me more specifically how to tell whether I run > xf86-input-keyboard or xf86-input-evdev? > kbd_drv.so is xf86-input-keyboard. evdev_drv.so is -evdev. > So I guess I don't have a layout specified yet: > > $ xkbcomp -xkb :0 out.xkb > Warning: Could not load keyboard geometry for :0 > BadAlloc (insufficient resources for operation) > Resulting keymap file will not describe geometry > > If I do not have a layout specified, what is the default that I have loaded? > What can I use as a starting template to start making modifications? > Ignore that message, and attach the out.xkb file.
Created attachment 19534 [details] output from `xkbcomp -xkb :0 out.xkb`
Thanks a lot so far. I found the !allowexplicit statements, killed them and loaded the resulting file. It doesn't seem to work, I don't get to control LEDs 1 and 2 the way I can control LED 3 Here's what I do: xkbcomp -xkb :0 out.xkb # edit out.xkb -> cracauer.xkb xkbcomp cracauer.xkb # now I have cracauer.xkm # load the sucker xkbcomp cracauer.xkm :0 # now read back to make sure I got what I wanted xkbcomp -xkb :0 l Unfortunately, led control on 1 and 2 still doesn't work. I tried both deleting the !allowexplicit lines and using allowexplicit (with no "!") instead. Neither worked. The above command sequence seems to be correct. I made a second edit exchanging END and HOME and that change takes effect. Also, in the file I read back allowwexplicit is not present for caps lock and num lock. It seems to me there's a problem here in changing an indicator that was !allowexplicit to allowexplicit. At least for after-startup loading.
> Here's what I do: > xkbcomp -xkb :0 out.xkb > # edit out.xkb -> cracauer.xkb > xkbcomp cracauer.xkb xkbcomp cracauer.xkb :0 does the job, you don't need to go through the xkm format. > Unfortunately, led control on 1 and 2 still doesn't work. I tried both deleting > the !allowexplicit lines and using allowexplicit (with no "!") instead. Neither > worked. works fine here. removing those two lines I can trigger the leds using "xset led". Are you talking about the XLeds option? If so, check your log file again, you are most likely using evdev for your keyboard. if the log contains "automatically adding devices" (about 30 lines down or so) and towards the end you can see a spew of various input devices being loaded, then you're using the evdev driver. You need to set Option "AutoAddDevices" "False" in your ServerLayout, and have a kbd section.
(In reply to comment #9) > works fine here. removing those two lines I can trigger the leds using "xset > led". Are you talking about the XLeds option? If so, check your log file > again, you are most likely using evdev for your keyboard. > > if the log contains "automatically adding devices" (about 30 lines down or so) > and towards the end you can see a spew of various input devices being loaded, > then you're using the evdev driver. > > You need to set Option "AutoAddDevices" "False" in your ServerLayout, and have > a kbd section. You mean a Section "InputDevice" Driver "kbd" ... , right? I have that. I added Option "AutoAddDevices" "False" to serverlayout and started a new X11 server. The log indicates I disabled automatically adding devices: (**) Not automatically adding devices I have xorg.conf and the logfile on http://www.cons.org/tmp/xorg/ But still, after loading the *.kbd with no !Allowexplicit lines I still don't get LED control. Still only LED 3, no LED 2 or 1. The numlock LED is still activated when pressing NumLock. Something's still klemming here. After you loaded the new *.kbd, does the NumLock LED still follow your NumLock key? %% Just one more word why I'm so inistent: the LEDs are pretty useful as indicator and I know there is interest out there. I maintain a program called ledbiff which uses them for mail indicators and I use them for other things, too. I have the download stats for ledbiff here and the feedback mail. The major problem people have is that you silently ignore the xset command and silently accept and ignore the Xleds statement in xorg.conf. In the past I just told my users to get rid of the xkb extension, but as of 7.3 that isn't possible anymore as keyboards without xkb are broken. I'd really like to track down why it works for you and not for me, as we seem to do the same steps, and make everybody be able to live with the xkb extension instead of going to recommend to them to use xorg 7.2 and disable it.
> The log indicates I disabled automatically adding devices: > (**) Not automatically adding devices > > I have xorg.conf and the logfile on http://www.cons.org/tmp/xorg/ For the future, please attach logfiles to the bug. it makes it easier to look at them if the remote server is down and is kept in archive. But yes, your setup appears correct. > But still, after loading the *.kbd with no !Allowexplicit lines I still don't > get LED control. Still only LED 3, no LED 2 or 1. The numlock LED is still > activated when pressing NumLock. Something's still klemming here. removing the !allowExplicit line works on git master and on xserver 1.5 here. what version are you running again? > After you loaded the new *.kbd, does the NumLock LED still follow your NumLock > key? yes, it follows numlock (we still have the entry in there after all) but it can now also be controlled by xset. If you don't want it to track numlock, just remove the whole indicator "Num Lock" block. > The major problem people have is that you silently ignore the xset command > and silently accept and ignore the Xleds statement in xorg.conf. The xkb stuff can be changed at runtime. in fact, from the xserver's point of view, you're first telling it to interpret xleds (in the driver) and _then_ you're telling it to only use the led for caps/num lock (during xkb init). So I daresay this is a bug in ledbiff, as you can get the information from the x server when ledbiff starts, and you could thus warn users that the leds cannot be used (or you just change the xkb description accordingly).
All right, sorry for the delay but I figured it is better that I try this on a second machine with newer X11 server and a fresh startover. Still no go. I have: - driver "kbd" section, in use - no mention of xleds or "XkbDisable" anywhere - log: "(**) Not automatically adding devices" - kbd file dump, edit and load procedure as above and verified that !allowexplicit is nuked from the leds No go. xset led only controls led 3, but not 2 and 1. Same as where I started. The new X11 server is 1.4.2 (Debian unstable), the other one I was posting about so far is 1.4.0.90. I don't know what else to try. What version are you using, again? As far as I am concerned this is back in "bug" now and I suggest we reopen this PR. I don't get the LEDs back when xkbcomp reports that they are now under explicit control. They aren't. I'm attaching conf, log and the output of the keyboard dump after the dump/edit/load cyle.
Created attachment 19730 [details] xorg.conf for the fresh attempt from last comment.
Created attachment 19731 [details] logfile for the fresh attempt from last comment.
Created attachment 19732 [details] verification that !allowexplict is now gone from the keyboard definition.
> The new X11 server is 1.4.2 (Debian unstable), the other one I was posting > about so far is 1.4.0.90. > > I don't know what else to try. What version are you using, again? git master and server 1.5 both work fine. not sure about 1.4.2.
I finally came around to try this with GIT versions of xorg from yesterday and the day before. It doesn't work, the behavior is the same that I described in comment #8. Led 3 works, leds 1 and 2 don't. Reopening.
Forgot to mention that one good thing about the git version is that it now emits an error message that I didn't see before: ~(disklesslibber)14% xkbcomp cracauer.xkm :0 Error: success in unknown Couldn't write keyboard description to :0
> --- Comment #18 from Martin Cracauer <cracauer@cons.org> 2008-12-03 19:19:38 PST --- > Forgot to mention that one good thing about the git version is that it now > emits an error message that I didn't see before: > > ~(disklesslibber)14% xkbcomp cracauer.xkm :0 > Error: success in unknown > Couldn't write keyboard description to :0 this means that the xkb description you're trying to load doesn't, so the changes never get applied. try with the xkb file, not with the xkm. xkm's tend to be a bit flakey.
Same error. Plus what is interesting is that getting a fresh kbd file out and reading it back in (without edits) gets me even more warnings. ~(disklesslibber)22% sud xkbcomp cracauer.xkb :0.0 Warning: Compat map for group 2 redefined Using new definition Warning: Compat map for group 3 redefined Using new definition Warning: Compat map for group 4 redefined Using new definition Error: success in unknown Couldn't write keyboard description to :0.0 ~(disklesslibber)23% xkbcomp -xkb :0 out.xkb Warning: Could not load keyboard geometry for :0 BadName (named color or font does not exist) Resulting keymap file will not describe geometry ~(disklesslibber)24% xkbcomp out.xkb :0.0 Warning: Compat map for group 2 redefined Using new definition Warning: Compat map for group 3 redefined Using new definition Warning: Compat map for group 4 redefined Using new definition Error: Key <> added to map for multiple modifiers Using Shift, ignoring Control. Error: Key <> added to map for multiple modifiers Using Mod1, ignoring Shift. Error: Key <> added to map for multiple modifiers Using Control, ignoring Mod1. Error: Key <> added to map for multiple modifiers Using Mod2, ignoring Control. Error: Key <> added to map for multiple modifiers Using Mod5, ignoring Mod2. Error: Key <> added to map for multiple modifiers Using Control, ignoring Mod5. Error: success in unknown Couldn't write keyboard description to :0.0
At least the GIT version gives more errors. Does this say anything to you? (EE) XKB: No components provided for device Virtual core keyboard (WW) Couldn't load XKB keymap, falling back to pre-XKB keymap This is printed to the log only after I try to start loading the new map. This is all I use for keyboard: Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" # Driver "keyboard" Option "CoreKeyboard" # Option "XkbRules" "xorg" # Option "XkbModel" "pc104" # Option "XkbLayout" "us" # Option "XkbDisable" EndSection
> --- Comment #21 from Martin Cracauer <cracauer@cons.org> 2008-12-04 09:10:39 PST --- > At least the GIT version gives more errors. > > Does this say anything to you? > > (EE) XKB: No components provided for device Virtual core keyboard > (WW) Couldn't load XKB keymap, falling back to pre-XKB keymap looks like it can't find the xkeyboard-config installation path. The VCK is hardcoded, so if it can't find the components there's something missing.
As of Xorg Server 1.7.7 this got even worse. Now control of the third LED (the only one working at the time of my bug report) has been removed as well. The procedure as described to remove "!" from AllowExplicit still does nothing. xkbcomp -xkb :0 out.xkb # edit out.xkb to remove "!" from allowExplicit in 3 or 4 places xkbcomp out.xkb :0 ==> xset led ==> [nothing happens] There are no error messages or warning either.
It's time to revisit this. Not only is the original problem still there. LED control in the xkb extension is not returned when editing and re-loading xkbcomp map, and of course the option not to use the xkb extension has been removed. Now it's worse, now the keyboard gets screws up by dumping from xkbcomp and reloading the same map. After doing this my window manager no longer recognizes Control-KP_6. It is always read as Control-KP_Right. I think that what is happening here is that numlock state I don't think there's a way to reset the keyboard either so this is causing a server death to get my KP_6 and friends back.
Now working as of X.Org version: 1.11.3 The following script will do the required work for you to enable LED control for programs such as ledbiff and flash them for 1 second. # ---- cut here ---- xkbcomp -xkb $DISPLAY ~/original.xkb # edit it to remove "!" from allowExplicit in 3 or 4 places perl -p -e 's/!allowExplicit;//gi;' < ~/original.xkb > ~/withleds.xkb xkbcomp ~/withleds.xkb $DISPLAY xset led sleep 1 xset -led
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.