LibretroAdmin 9696bef97a udev: player lights through the pad's LED devices ...

The udev joypad driver lit nothing: it had no set_player, unlike the
other desktop drivers. It now finds the LED class devices under each
pad (its HID device, or an Xbox 360 pad's USB device) and lights them
as each console does: a DualSense's five player lights, a DualShock
4's light bar in the player's colour, a DualShock 3's four, a Switch
pad's four and an Xbox 360 pad's ring. A DualSense's light bar is left
alone, as are lights it never lit; ones it lit go out when no port
reads the pad. Four rings under one wireless receiver are not told
apart, and are left.

Writing a light can wait on the pad (a Switch pad answers a request),
so the rumble writer's thread writes them: the lights are opened where
a pad arrives and handed over through atomic slots, with the player
wanted an atomic of its own. Without threads the caller writes them,
as with rumble. A driver that adds a pad's lights just after its input
nodes is looked at again a few times.

The kernel makes these files root's.
pkg/linux/70-retroarch-player-lights.rules makes them writable by the
user; without it the pad is left as it is, and the log says so.

samples/input/udev_player_lights runs the real driver against a
directory laid out as /sys is, under ASan and TSan.

2026-10-27 12:36:07 +01:00

..

70-retroarch-player-lights.rules

udev: player lights through the pad's LED devices

2026-10-27 12:36:07 +01:00