[PATCH] [RFC] ALSA: control - add generic LED API to sound core routines

[Takashi Iwai]

On Mon, 08 Feb 2021 17:17:29 +0100,
Jaroslav Kysela wrote:
> 
> Dne 08. 02. 21 v 16:11 Takashi Iwai napsal(a):
> > On Sun, 07 Feb 2021 21:11:57 +0100,
> > Jaroslav Kysela wrote:
> >>
> >> [DO NOT MERGE!]
> >> [This is just an early proposal for comments]
> >> [The code is not tested / debugged]
> >>
> >> The recent laptops have usually two LEDs assigned to reflect
> >> the speaker and microphone mute state. This implementation
> >> adds a tiny layer on top of the control API which calculates
> >> the state for those LEDs using the driver callbacks.
> >>
> >> Two new access flags are introduced to describe the controls
> >> which affects the audio path settings (an easy path for drivers).
> >>
> >> The LED resource can be shared with multiple sound cards with
> >> this code. The user space controls may be added to the state
> >> chain, too.
> >>
> >> This code should replace the LED code in the HDA driver and
> >> add a possibility to easy extend the other drivers (ASoC
> >> codecs etc.).
> > 
> > Having a common helper in the ALSA core sounds like a good way to go.
> > 
> > My slight concern is that this will end up having the dependency on
> > LEDS stuff unconditionally when CONFIG_SND_LED=y.
> 
> You probably mean that the LEDs subsystem is activated even if we don't have
> audio LED class driver connected, right?

Yes.

> I think that the HDA way (select conditionally the LED code) in the low-level
> driver Kconfig is good, but I'm open for any other suggestions.

Well, in the case of HD-audio, it's only for HD-audio.  But with this
change, LEDS class will be always loaded on distro kernels no matter
which sound driver is actually used.

I guess we can split the LED-support code to another module?
The problem would be the registration from the control core.  The
other parts look already isolated enough.


> > Also, are those new access flags exposed to user-space intentionally,
> > so that user-space gets some information?
> 
> Yes, it's one benefit, the second benefit is that we can create user space
> controls for hardware which does not have any switch / volume controls for the
> given path.
> 
> An example is the AMD ACP bridge with the simple digital microphones. We can
> use alsa-lib's softvol plugin to control the volume for this and it would be
> nice to mark this user space control with the mic mute LED flag.

OK, makes sense.


> > Last but not least: I'm not sure whether we should limit to only two
> > LEDs (mic and spk).  I'm afraid that there will be more LEDs in
> > future; people love decorations :)
> 
> We have some more free bits in the access field. If the LED count will
> increase in future for the standard hardware, we should reconsider the
> implementation (info callback or so).
> 
> Perhaps, it may be clever to reserve three bits from the access flags now (to
> create a three bit value not a mask). In this case, we can carry information
> for 7 LED types (assuming that one control element can be assigned only to one
> LED type).

Sounds like a good idea.  I guess 4 types would suffice for now.


thanks,

Takashi