# On-board LEDs - Feature Requests **URL:** \ **Category:** Product support\ **Created:** [August 24, 2021, 8:27am UTC](https://forums.balena.io/t/on-board-leds-feature-requests/345263 "2021-08-24T08:27:16Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![hsghost](https://avatars.discourse-cdn.com/v4/letter/h/da6949/32.png) [@hsghost](https://forums.balena.io/u/hsghost)\ **Post date:** [August 24, 2021, 8:27am UTC](https://forums.balena.io/t/on-board-leds-feature-requests/345263/1 "2021-08-24T08:27:16Z")
Continuing the discussion from [Controlling onboard LEDs on Rpi 4](https://forums.balena.io/t/controlling-onboard-leds-on-rpi-4/126102): Read this thread and happy to hear that the dev team is working on solutions to better control the on-board LEDs. Yet, to elaborate a little more on our own project requirements and to give the devs another practical example, I would like to start this new thread. The board on our hand is a ASUS Tinker Board. It has three LEDs on board - the **RED** , the **GREEN** and the **YELLOW**. Our goal is to build a screen-less control unit for a vending machine. So these on-board LEDs are critical for quickly identifying issues on a field environment. Ideally, we would like the following design: **GREEN** - SOLID\_ON for power-on. BLINK for OS related, non-operational, non-critical activities/issues like disk writes and network drops - just as the current blink patterns when VPN goes off. Yet, these triggering signals has to be inverted in order to combine them with the solid power-on signal to actually create the blinks. And the blinks has to be muxed, too, so that multiple triggers can be gracefully blend into one single output. This design would help us to identify network issues, as well as to hint us with our best efforts to avoid a power unplugging during busy disk writes. **YELLOW** - DEFAULT\_OFF. SOLID\_ON/BLINK for service related, operational triggers like GPIO activities, UART transmission, I2C transmission, SPI transmission, or even PWM controls. Surely, we can do this from user code. Yet, it’d be more elegant for the kernel to provide such facilities to offload our user space coding. **RED** - DEFAULT\_OFF. BLINK for thermal over heating, eFuse, etc., system-related faults or warnings. SOLID\_ON for service related exceptions, like a door being blocked from closing or RFID reading errors. This latter one should be signaled from user code, of course. Still, a mux mechanism is needed for these signals to properly overlaying with each other. Also, the kernel should provide set-and-forget APIs for user code to register such triggers and patterns so that async code could be better devised. **RED AND YELLOW** - INTERLEAVE\_BLINK for kernel panic, such as accidentally removal of a SD card, so that we can safely cycle the power under such dead circumstances. We have tried hard on Device Tree to achieve these desired features. Yet, from what we have tested, the current implementation seems to be incapable. Especially, the `trigger-sources` and `function` properties on the `led` nodes seems to get completely ignored. The only well working property seems to be the `linux,default-trigger`, and its few acceptable options are a mix of limited trigger sources and some ambiguous patterns: ```auto # cat /sys/class/leds/led1-led/trigger [none] rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock mmc0 mmc1 timer oneshot heartbeat backlight gpio cpu0 cpu1 cpu2 cpu3 default-on mmc2 rfkill0 rfkill1 ``` \_ While a large portion of these triggers are rarely used keyboard indicators, the `"mmc0"` and `"gpio"` are the sole two left for us to be interested in. Yet, as there’s currently no muxing, setting the `"mmc0"` option will take precedence over `default-state = "on"`, rendering the LED to become normal-off and showing SD card access only. We have no option but to dedicate the **GREEN** LED to power-on, and move the `"mmc0"` trigger to the **YELLOW** one, dropping any service related activities and showing only abnormal states through user code on **RED**. Unfortunately, as we move the pointer in `supervisor.conf` to the **RED** , without extra muxing code the same masking effect either mutes all our custom alarms, only showing the network status, or vice versa. Following is the snippet from the current dts file we’re using: ```auto gpio-leds { compatible = "gpio-leds"; red-led { gpios = <0x2d 0x03 0x00>; linux,default-trigger = "default-off"; }; grn-led { gpios = <0xa8 0x18 0x00>; linux,default-trigger = "default-on"; }; ylw-led { gpios = <0xa8 0x19 0x00>; linux,default-trigger = "mmc0"; }; }; ``` Little to elaborate, we just renamed the LEDs for easy identification. However, we propose taking full advantage of the data tree semantics to achieve the desired results, as follows: ```auto thermal-zones { ... soc-thermal { ... trips { soc-crit: soc-crit { ... #trigger-source-cells = <0x02>; // Setting parameter numbers to 2. }; }; }; ... }; ... gpio-leds { compatible = "gpio-leds"; red-led { gpios = <0x2d 0x03 0x00>; default-state = "on"; // Setting the default state; // BLINK signals should automatically get inverted upon setting this to "on". trigger-sources = <&soc-crit LED_SLOW_BLINK 0x01>, <&efuse@ffb40000 LED_FAST_BLINK 0x02>; // Phandle with two parameters: // <&phandle PATTERN precedence>, // same precedence number means // a direct combination. panic-indicator = "true"; // LEDs including this property should be signaled to INTERLEAVE_BLINK upon a kernel panic. }; ... }; ``` \_ Well, this certainly means to modify the `gpio-leds` driver. As we are busy implementing our own services, there’s no time for us to look into the kernel drivers and build our customized image. So, we’re going with the current settings, and in hope for an official release to provide such improvements. I’ve given enough discussion on our real world example, I believe. We sincerely wish that the dev team can make more polish on the BalenaOS, to unleash the full power of SBCs! ---
**Author:** ![mpous](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/mpous/32/4742_2.png) [@mpous](https://forums.balena.io/u/mpous)\ **Post date:** [November 4, 2021, 12:56pm UTC](https://forums.balena.io/t/on-board-leds-feature-requests/345263/5 "2021-11-04T12:56:03Z")
Thank you very much @hsghost for your feature request. Internally we opened a feature request about your comment. We will keep you updated!