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