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

[Jaroslav Kysela]

Dne 08. 02. 21 v 23:34 Takashi Sakamoto napsal(a):
> Hi,
> 
> On Mon, Feb 08, 2021 at 05:33:02PM +0100, Takashi Iwai wrote:
>>>> 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.
> 
> I have a concern about the usage of access flag for such kind of
> hardware specific stuffs (LED dedicated to specific audio control)
> since it's not enough hardware abstraction.
> 
> In my opinion, for the case, developers for in-kernel driver tend to use
> specific name for control elements (or prefix/suffix of the name). Adding
> new access flags for it seems to be overengineering against the original
> purpose.

Unfortunately, the ASoC drivers do not take care about any abstract naming.
They mostly follow hw (codec) register naming from datasheets. So this rule is
no longer true.

> The patch itself includes some remarkable ideas that:
>  - introduction of association between control elements
>  - analyzing current status of the association (then operate LEDs)
>  - communication to userspace stuffs about the association
> 
> (here I carefully avoid usage of word 'topology'.)
> 
> The association itself seems to be useful when cooperating use case manager
> of alsa-lib. I guess that the kind of framework designed for the association
> is preferable instead of the patch tight-coupled to LED stuffs.
> (And some subsystem already attempts to implement such framework into kernel
> land, e.g. media controller devices in media subsystem.)
> 
> 
> In another side, I guess that the reason to supply the association to
> kernel land is to use 'ledtrig_audio_set()' kernel API. If userspace
> stuffs find target LEDs and operate them via userspace interface,
> the association could be in userspace. I think it better to investigate
> for the direction since I can imagine that the introduction of association
> to kernel land brings much codes into kernel land to support wide-variety
> of hardware (and going to be obsoleted according to lifetime of actual
> hardware sooner or later).

My goal is to:

1) reduce the code required to the LED support in the drivers
2) handle security - see the Takashi follow up; for very secure
   kernel configurations, the user space (non-root) should not "touch" the
   LED settings at all to have the right feedback; also UCM is a bit
   another layer on top of the other APIs

The user space solution was already a bit denied when the LED support was
added to the HDA driver (we can see the similarity for the vmaster code which
is another layer in the control code etc.).

I almost finished the complete implementation in the separate kernel module
and the current snd.ko (control) code has minimal modifications just to
redirect the necessary things to make the LED layer operational. It seems that
we can save the code in the HDA driver and we can do really light changes in
other drivers (set flags and do module load) just to get LED working without
any user space intervention.

If we come with another framework or solution in the future, we can remove
this layer (it's just one small file / module). At least, we will have marked
(the new access flags) the related controls / drivers / hardware.

				Jaroslav

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