On Mon, 21 Sep 2020 01:31:23 +0200
"Adrian Schmutzler" <mail@xxxxxxxxxxxxxxxxxxx> wrote:
> > > link3 {
> > > function = LED_FUNCTION_RSSI;
> > > color = <LED_COLOR_ID_GREEN>;
> > > gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
> > > };
> > > };
> > Well, this is not really three LEDs. This is more like... LED meter
> > composed of three LEDs. And we don't have good support for that.
> > But I guess we'll need it one day. There were some previous attempts:
> > https://lwn.net/Articles/802967/
> > Do you plan to control RSSI LEDs from kernel?
>
> To be honest, I mostly sent this patch for completeness.
>
> OpenWrt uses a very simple process written in C for updating these LEDs, which is quite old and has essentially remained unchanged for years, but does its job.
> I personally don't think there will be overwhelming interest in touching this and migrate it to whatever different implementation without a pressing need.
>
> My main interest here was/is that I started to evaluate how OpenWrt can migrate from LED labels to the "new" color/function syntax and to me the rssi leds are a dedicated type that should be supported.
> So I fear I won't be helpful for the implementation of RSSI leds in the kernel in general.
>
> For the three leds vs. set of leds discussion: Note that we are interested in (and already do) exposing each LED to the user individually (in user-space via sysfs), so the user can redefine the purpose of the LED freely based on his/her desire. Therefore, a total abstraction of the set of LEDs as a single entity would be detrimental for us here.
>
> Best
>
> Adrian
This is interesting. How does this work? Better signal => faster
blinking?
Where is the signal strength taken from?
Marek
