multicolor virtual color LED driver.

[Jonathan Brophy <Professor_jonny@xxxxxxxxxxx>]

In OpenWrt there is a preference to control leds via kernel solutions and triggers/ aliases from the device tree the problem is that the underlying structure means that multicolor or grouped multicolor LED's are not supported without per device userscripts to customise led behaviour, so often RGB status leds are relegated to glorified power leds  for simplicity.

I wish to make better use of multicolour LED's for device status but are finding that a universal solution is not really possible and may be so with other projects or Linux based solutions.

Problems also arise that the potential for multiple triggers to be operated at the same time causing two or more potential leds operating at the same time and showing incorrect status from mixing of the colours.

I'm wondering if a simple solution would be to create a driver to provide virtual colour leds by splitting multicolour or grouped singular leds into virtual individual led colours so they can be connected to an individual trigger.

Driving color with in the OpenWrt means applying multiple triggers to individual RGB elements to drive colour, just the simple process of being able to pick virtual colours from the primary and secondary RGB colour model would be handy.

To fix the issue of multiple individual colours mixing by two or more statuses driving at the same time would be to provide a priority element via config or directly in the DTS to only show the most important status of potentially operated virtual leds(example below of a potential DTS solution below)
As multiple staged led's one after the other in a flashing Christmas tree like situation that is not handy as a status led.

If priority is the same, it could stage LED's one after the other for equally important statuses..

I'm wondering if this driver addition or something along these lines would be possible and welcomed or any such advice or a such with this problem?



monochromatic-leds {
    compatible = "gpio-leds";

    led-0 {
        gpios = <&&tlmm 50 GPIO_ACTIVE_HIGH>;; // green
    };

    led-1 {
        gpios = <&tlmm 51 GPIO_ACTIVE_HIGH>; // red
    };

    led-2 {
        gpios = <&tlmm 52 GPIO_ACTIVE_HIGH>; // blue
    };
};

virtual-led-group {
    compatible = "leds-group-virtualcolor";

    multi-led {
      color = <LED_COLOR_ID_RGB>;
      function = LED_FUNCTION_INDICATOR;
      max-brightness = <256>;

      led_system_green: led0 {
        color = <LED_COLOR_ID_GREEN>;
        leds = <&led-0>;
        priority = <0>  //top priority override everything
        linux,default-trigger = "heartbeat";      
      };
    
      led_system_red: led1 {
        color = <LED_COLOR_ID_RED>;
        leds = <&led-1>;
        priority = <1>      
      };
    
      led_system_blue: led2 {
        color = <LED_COLOR_ID_BLUE>;]
        leds = <&led-2>;
        priority = <1>      
      };
    
      led_system_yellow: led3 {
       color = <LED_COLOR_ID_YELLOW>;
        leds = <&led-0>,<&led-1>;
        priority = <1>
      };
    
      led_system_magenta: led4 {
        color = <LED_COLOR_ID_MAGENTA>;
        leds = <&led-1>,<&led-2>;
        priority = <2>  
      };
    
      led_system_cyan: led5 {
        color = <LED_COLOR_ID_CYAN>;
        leds = <&led-0>,<&led-2>;
        priority = <2>  
      };
    
      led_system_white: led6 {
        color = <LED_COLOR_ID_WHITE>;
        leds = <&led-0>,<&led-1>,<&led-2>;
        priority = <3> 
      };
    };
};

Also, of note On color wheels of the RGB (additive) and CMY (subtractive) color models magenta is a standard reference color but is not an available color ID in leds/common.h not so much an issue just a note and I don't know if such an addition of this color would be a good idea?