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

[Jaroslav Kysela]

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?

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.

> 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.

> 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).

					Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.