Front-panel RGB notification LEDs

Identity

Status — ● working

All three LEDs are driven through FreeBSD’s stock gpioled(4) and appear as /dev/led/led-red, /dev/led/led-green, /dev/led/led-blue. Writing 0, 1, or any FreeBSD led(4) blink pattern (f5, s10, etc.) directly to those device nodes works without root once the device permissions are set up. omfreebdy ships a small phone-led userland helper that wraps the device files behind a narrow root helper so user-session scripts can flash the LED on notifications.

Driver

• Our tree: none — DTS overlay only. The gpio-leds node lives in our PinePhone Pro DTS overlay and pulls in the upstream gpioled driver unchanged.
• Linux mainline: drivers/leds/leds-gpio.c
• FreeBSD upstream: sys/dev/led/led.c plus sys/dev/gpio/gpioled.c

gpioled(4) walks FDT gpio-leds nodes, allocates a GPIO output per child, and registers it with the led(4) framework. The framework provides the /dev/led/<name> device node and the blink-pattern grammar — drivers do not need to implement timing themselves. The PinePhone Pro DTS names the three children led-red, led-green, led-blue so the device-node names match the colors directly.

Open work

• A unified phone-side notification daemon that drives the LED based on missed calls / charge state / silenced ringer would be more useful than the current ad-hoc shell wrappers.
• PWM-driven brightness is not wired up — the LEDs are full-on or full-off only.

Related

• Where we are now — system peripherals section, links to the omfreebdy userland helper.
• Vibration motor — the other notification-class output, now split back out as a gpio-vibrator / FF_RUMBLE candidate instead of a gpioled child.
• Hardware reference — full chip manifest.