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
