I'm wondering if we can add the kmod's to support multicolor class brightness /pwm and for grouped monochromatic LED's?
The complete TP link deco range of devices only have a single lamp device to indicate status, and it would be nice to mimic some of the features of the status led with comparable OpenWrt features.
Find led setup in luci
the currebt setup in luci It is not really suitable be able to drive rgb colours from a single monocromatic led
There is no dimming and pwm support or priority of led outputs from the bindings in luci , I plan to make my own scripts to control these things but kernel support for it would make control a lot easier.
I believe I have seen PWM support of GPIO LEDs in custom kernel modules from some vendors, but as far as I know in mainline it only exists for LEDs connected to a PWM controller. It would be a nice feature, but not for the purpose you intend: It's real use is dimming of LEDs, not indicating differences.
Case in point: Do you expect yourself or anyone else to distinguish between
indicating one status and
indicating another, even though they differ by 50% brightness on one channel?
"Multicolor LEDs" on the other hand seem like a rather useless abstraction, they still require to set three values, just in one place instead of three, at the cost of not having the individual LEDs controllable by separate events anymore.
We briefly touched on that in your previous thread: Most of what the original firmware is communicating through the LED are statuses of its mesh integration, but there are precious few equivalents on an OpenWrt system. I'm still not sure what exactly you intend to communicate by means of different shades of color.
Wouldn't it be more appropriate to assign the status of individual system components to individual LEDs? You can have the general system status on blue, the wireless on red, and the wired LAN on green. A system would boot up into blue, go into purple if joined by the wifi, and into full white if all three components are up and running. Add a netdev rx/tx trigger and you have pretty multicolor blinkenlights. All without PWM and multicolor LED shenanigans.
Other may want it to play guest wifi password in Morse. You cant sync blinking of multiple leds, so it is not really rgb.
Im not really worried about the shades of colour just the primary and secondary colours that would be:
Red
Green
Blue
Yellow
Cyan
Magenta
White
In the stock device you could only call those colours at even mix of each, i'd be happy with that but having the ability to dim or fade each led as a group would make transition nicer just the the stock device.
I can script the colours to functions and give each a time slot but having fading or dimming would be nice.
You need neither PWM nor a multicolor LED abstraction to create those.
And yes, as I said, dimming LEDs would be nice. But as far as I am aware no kernel module exists that would allow PWM on LEDs attached to GPIOs.
I cant define virtual led's in the dts like the oem has, I would have to drive the colors my mixing them in userspace it gets more complicated.
it would be nice of the kernel controlled the led's and i just create bindings in the led menu and it rolls the sequence of led's one after the other without user intervention or external scripts.
there is gpio_pwm kernel mods but it is a bit of a hack:
[OpenWrt Wiki] PWM emulation with GPIO
leds {
compatible = "gpio-leds";
red {
gpios = <&tlmm 51 GPIO_ACTIVE_HIGH>;
default-state = "on";
};
green {
gpios = <&tlmm 50 GPIO_ACTIVE_HIGH>;
default-state = "on";
};
blue {
gpios = <&tlmm 52 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
yellow_mix {
default-state = "off";
virtuals = <0>, <1>, <3>;
};
blue_mix {
default-state = "off";
virtuals = <1>, <2>, <3>;
};
};
};
What's so complicated about it?
#!/bin/sh
# a super handy function
set_rgb_leds() {
echo $1 > /sys/class/leds/whatever:red/brightness
echo $2 > /sys/class/leds/whatever:green/brightness
echo $3 > /sys/class/leds/whatever:blue/brightness
}
# call it with three parameters:
set_rgb_leds 255 0 0 # red
set_rgb_leds 0 255 0 # green
set_rgb_leds 0 0 255 # blue
set_rgb_leds 255 255 0 # yellow
set_rgb_leds 255 0 255 # purple rain
set_rgb_leds 0 255 255 # ooh, cyan!
set_rgb_leds 255 255 255 # white
I believe you're overthinking all of this.
that was my original intention, but it all requires scripting I still have bind the led's to linux triggers, an I have to create logic to cycle so that only one trigger is active at a time I can't just bind them with the led menu in luci it would not work..
I was hoping the functionality of the kernel module would just export the led defined in the dts so I can run them directly as pseudo single led's I can bind in luci.
The Kernel module would do the magic to cycle each one after the other, yes it can be done with scripting as you suggest but it is more complicated than tjust binding the led in luci and it just work.
I don't know if such a proposal would be beneficial by adding a special kmod multicolour led class status or something?
it would require a clock signal (2 second pulse or something) and cycle through each trigger and display it. by converting each trigger to select the aproprate binary output trigger to the LED intended colour.
Sorry, you lost me. I can't figure out how that is not going to end up a chaotically blinking christmas tree ornament rather than a method to convey information to anyone. But that's probably just me thoroughly misunderstanding what you have in mind.
At any rate, I'm fairly certain such kernel modules do not exist, you would have to write them. And convincing the maintainers to include them in in OpenWrt, let alone upstream, will be an uphill battle. You've got quite the task ahead of you. Good luck!
This is sort of what I was planning I have my states from external triggers and a big while loop sequencing each state.
This works to cycle the led colours I just need to put in the triggers I'm not sure on that bit is there a list of triggers somewhere?
#!/bin/sh
# setup easy led drive functions
set_rgb_leds() {
echo "$1" > /sys/class/leds/red:/brightness
echo "$2" > /sys/class/leds/green:/brightness
echo "$3" > /sys/class/leds/blue:/brightness
}
while :
do
state0=1
state1=1
state2=1
state3=1
state4=1
state5=1
state6=1
if [ "$state0" = "1" ]; then
set_rgb_leds 255 0 0 # red
sleep 2
else
set_rgb_leds 255 0 0 # off
fi
if [ "$state1" = "1" ]; then
set_rgb_leds 0 255 0 # green
sleep 2
else
set_rgb_leds 255 0 0 # off
fi
if [ "$state2" = "1" ]; then
set_rgb_leds 0 0 255 # blue
sleep 2
else
set_rgb_leds 255 0 0 # off
fi
if [ "$state3" = "1" ]; then
set_rgb_leds 255 255 0 # yellow
sleep 2
else
set_rgb_leds 255 0 0 # off
fi
if [ "$state4" = "1" ]; then
set_rgb_leds 255 0 255 # purple rain
sleep 2
else
set_rgb_leds 255 0 0 # off
fi
if [ "$state5" = "1" ]; then
set_rgb_leds 0 255 255 # ooh, cyan!
sleep 2
else
set_rgb_leds 255 0 0 # off
fi
if [ "$state6" = "1" ]; then
set_rgb_leds 255 255 255 # white
sleep 2
else
set_rgb_leds 255 0 0 # off
fi
done
Ok so I have been playing to create my own kernel driver as it is kind of a pain to script and monocromatic led's are no better than single leds and you can't operate them luci .
I have come up with something that will create virtual led's by grouping physical led's.
dimming will work for the group of led's virtually grouped.
With this I can issue triggers in luci and assign aliases in the dts to operate any mixed color.
aliases {
led-boot = &led_virtual_yellow;
led-failsafe = &led_virtual_blue;
led-running = &led_virtual_yellow;
led-upgrade = &led_virtual_green;
serial0 = &blsp1_uart5;
};
leds {
compatible = "gpio-leds";
pinctrl-0 = <&led_pins>;
pinctrl-names = "default";
/*note the LED's defined here are not individual they are a single combined RGB element
they will be overriden by the virtual leds if the led's group virtual colour
kernel driver iS loaded */
led_system_green: green {
gpios = <&tlmm 50 GPIO_ACTIVE_HIGH>; /* green led component of rgb led */
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_INDICATOR;
};
led_system_red: red {
gpios = <&tlmm 51 GPIO_ACTIVE_HIGH>; /* red led component of rgb led */
color = <LED_COLOR_ID_RED>;
function = LED_FUNCTION_INDICATOR;
};
led_system_blue: blue {
gpios = <&tlmm 52 GPIO_ACTIVE_HIGH>; /* blue led component of rgb */
color = <LED_COLOR_ID_BLUE>;
function = LED_FUNCTION_INDICATOR;
};
};
virtualcolor_leds {
compatible = "leds-group-virtualcolor";
/*note the LED's defined here are virtual
by mixing the individual colors of the monochromatic system led.*/
led_virtual_red: virtual_red {
color = <LED_COLOR_ID_RED>;
function = LED_FUNCTION_STATUS;
leds = <&led_system_red>;
};
led_virtual_green: virtual_green {
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_STATUS;
leds = <&led_system_green>;
};
led_virtual_blue: virtual_blue {
color = <LED_COLOR_ID_BLUE>;
function = LED_FUNCTION_STATUS;
leds = <&led_system_blue>;
};
led_virtual_yellow: virtual_yellow {
color = <LED_COLOR_ID_YELLOW>;
function = LED_FUNCTION_STATUS;
leds = <&led_system_green>, <&led_system_red>;
};
led_virtual_cyan: virtual_cyan {
color = <LED_COLOR_ID_CYAN>;
function = LED_FUNCTION_STATUS;
leds = <&led_system_green>, <&led_system_blue>;
};
led_virtual_violet: virtual_violet {
color = <LED_COLOR_ID_VIOLET>;
function = LED_FUNCTION_STATUS;
leds = <&led_system_red>, <&led_system_blue>;
};
led_virtual_white: virtual_white {
color = <LED_COLOR_ID_WHITE>;
function = LED_FUNCTION_STATUS;
leds = <&led_system_green>, <&led_system_red>, <&led_system_blue>;
};
};
