2

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?

Niko
  • 555
  • 4
  • 8
  • 16

2 Answers2

4

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.

EDIT:

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.

Dmitry Grigoryev
  • 7,123
  • 2
  • 23
  • 62
  • 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 '15 at 19:08
  • Actually, could you clarify what `bInterfaceClass` and `bInterfaceSubClass` are/do? – Niko Nov 16 '15 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. – Dmitry Grigoryev Nov 16 '15 at 19:28
-2

/etc/udev/rules.d/keyboardled.rules

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

Nill Morais
  • 7
  • 2
  • 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](/help/how-to-answer). – Community Dec 21 '22 at 21:37