I have a very simple generic gaming keyboard with a backlight. The, typically, universal way to engage the backlight is with xset led 3. I can confirm that this does in-fact work. Because I have two computers that I switch back and forth from with a peripheral switch, however, this becomes problematic because when I switch from one context to the other I'm unplugging and plugging the USB back in.

I wrote a file /etc/udev/rules.d/keyboard.rules with the following rule:

ATTRS{idVendor}=="258a", ATTRS{idProduct}=="0001", RUN+="/bin/bash -c \"DISPLAY=:1;xset led 3;\""

If I run /bin/bash -c \"DISPLAY=:1;xset led 3;\" by itself it works just fine, however, it doesn't seem to work as just a rule. It only sometimes turns on, and when it does it flashes on and then immediately turns back off. I have checked multiple times over and I know that my idVender and idProduct are correct:

Bus 003 Device 079: ID 258a:0001

What else could I be missing?

  • Are you sure that xset doesn't need export XAUTHORITY="/home/<user>/.Xauthority" to work? Nov 16, 2015 at 16:10
  • I gave it a try and there was no change, unfortunately.
    – Niko
    Nov 16, 2015 at 17:19

2 Answers 2


I believe the issue is that your rule is triggered multiple times (you can verify if this is the case with udevadm monitor). Each xset command flips the state of the leds, causing them to flash shortly and go off again. You should make your rule more specific, e.g.:

ACTION=="add", ENV{DEVTYPE}=="usb_interface", ATTRS{idVendor}=="258a", ATTRS{idProduct}=="0001", RUN+="/bin/bash -c \"DISPLAY=:1 xset led 3;\""

If that doesn't help, you may need to investigate further and perhaps specify bInterfaceClass and bInterfaceSubClass attributes to your rule.


Another theory I have about your hardware is that the udev rule is executed too early, when the keyboard is not yet ready to accept the led commands. Try "/bin/bash -c \"sleep 5;DISPLAY=:1 xset led 3;\"" and report what happens. Also, some more remarks

  1. I hope you're sure your DISPLAY is actually :1, not :0.

  2. Note how I attached DISPLAY variable to the xset command. DISPLAY=:1 by itself set the DISPLAY variable for bash, not for xset.

  3. You may also want to add XAUTHORITY="/home/<user>/.Xauthority" in the mix.

  • That does make sense, but in my instance I have to turn the leds on with xset led 3 and xset -led 3 to turn them off. Running xset led 3 in rapid succession doesn't actually have any affect on the keyboard (I can run watch -n 0.1 xset led 3 and it just stays on without toggling). You are correct in that I see udevadm monitor call does indeed show the multiple events with the keyboard when I plug it in. I will have to investigate further, because adding your rule definition doesn't improve the current situation.
    – Niko
    Nov 16, 2015 at 19:08
  • Actually, could you clarify what bInterfaceClass and bInterfaceSubClass are/do?
    – Niko
    Nov 16, 2015 at 19:09
  • Those identify individual USB interfaces. Keyboards typically have separate interfaces for the keyboard itself, the touchpad (if any) and the ACPI keys. Even if you don't have the touchpad and the power keys, your keyboard chip may support those, and in that case the USB interfaces will still be there. Nov 16, 2015 at 19:28


ACTION=="add", ATTRS{idVendor}=="1c4f", ATTRS{idProduct}=="0002", RUN+="/bin/sh -c 'DISPLAY=:0.0 XAUTHORITY=/home/nill/.Xauthority sh -c "xset led 3" &'"

it's working.... =D

  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Dec 21, 2022 at 21:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .