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

[Takashi Sakamoto]

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.


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


Regards

Takashi Sakamoto