I've created a udev rule for this that works just fine. First it's needed to identify device attributes once the controller is connected, e.g.:
udevadm info -a -p $(udevadm info -q path -n /dev/input/js0)
This will print a bunch of useful information that can be used to create a udev rule to match the device once it's connected, and execute something.
Here, I've picked ATTRS{uniq}
to indentify my controller in specific (one can also use a more general DualShock 4 match, picking ATTRS{name}=="Wireless Controller"
for example):
/etc/udev/rules.d/10-local.rules
# Set First DualShock 4 LED color
ACTION=="add", SUBSYSTEM=="input", ATTRS{uniq}=="dc:0c:2d:d3:a7:0c" RUN+="/usr/local/bin/ds4led '%p' 000100"
It's possible to control LED brightness and color by writing RGB values to paths similar to the following:
echo 255 | sudo tee /sys/class/leds/0005:054C:09CC.000B:blue/brightness
The above sets my controller's blue component to maximum brightness. The 0005:054C:09CC.000B
part of the path may vary per connection.
The previous udev rule executes the following script, which accepts two arguments, a path that contains a pattern like 0005:054C:09CC.000B
, which it extracts to build the /sys/class/leds/0005:054C:09CC.000B:blue/brightness
path, and a color in the RRGGBB form:
/usr/local/bin/ds4led
(do not forget to set executable permission for this)
#!/bin/bash
RED=$((16#${2:0:2}))
GREEN=$((16#${2:2:2}))
BLUE=$((16#${2:4:2}))
LED=$(echo "$1" | egrep -o '[[:xdigit:]]{4}:[[:xdigit:]]{4}:[[:xdigit:]]{4}\.[[:xdigit:]]{4}')
[[ -z "$LED" || ! -d "/sys/class/leds/$LED:global" ]] && exit
echo 0 > /sys/class/leds/$LED:red/brightness
echo 0 > /sys/class/leds/$LED:green/brightness
echo 0 > /sys/class/leds/$LED:blue/brightness
echo $RED > /sys/class/leds/$LED:red/brightness
echo $GREEN > /sys/class/leds/$LED:green/brightness
echo $BLUE > /sys/class/leds/$LED:blue/brightness
ds4led
can both be called manually like sudo ds4led /sys/class/leds/0005:054C:09CC.000B:global 0000FF
or from a udev rule by passing %p
as the first argument. Even though udev will pass a devpath
that's completely different from /sys/class/leds/...
, it'll still contain a pattern like 0005:054C:09CC.000B
in it.