[PATCH v4 6/6] ALSA: led control - add sysfs kcontrol LED marking layer

[Takashi Iwai]

On Tue, 23 Mar 2021 12:13:12 +0100,
Jaroslav Kysela wrote:
> 
> Dne 23. 03. 21 v 11:50 Takashi Iwai napsal(a):
> 
> >>> - Specifying the numid may the code simpler in kernel side?
> >>>   alsactl has already the string parser.
> >>
> >> Yes, but it's not so handy for scripting / UCM. I can add find-ctl-numid
> >> lookup to UCM, of course, but what about standard shell scripting?
> > 
> > Hmm, would UCM itself touch the sysfs entry?  That sounds a bit awful.
> 
> I already described that with UCM, the boot initialization sequences can be
> put in the top-level UCM configuration file to replace the standard (legacy)
> alsactl initialization, because ASoC does not use the standard control names
> (so the lagacy init does not work). Those boot sequences are supposed to run
> at boot / card initialization phase only. This sysfs setup should be placed
> only to those sections. The motivation is to have the card configuration in
> the one place.
> 
> > The simpler implementation in the kernel side is always nicer, but of
> > course only if it works sufficiently.  So it depends on how much we
> > want to support this feature.  The parse of control name can be done
> > by scripting, but it's cumbersome for now, indeed, so if the shell
> > scripting is seen as the major usage, it'd be more convenient if the
> > kernel parses the string, yeah.
> > 
> >>> - Do we have to deal with binding with multiple controls to a single
> >>>   mute LED?  Might a single exclusive binding make things easier?
> >>>   Then we don't have to create sysfs entries per card, and it'll be
> >>>   something like
> >>>      echo 1:10 > /sys/devices/virtual/sound/ctl-led/mic/bind
> >>>   which is equivalent with the API call above.
> >>>   If multiple bindings are attempted, it can simply give an error.
> >>>   In the driver side, it catches the unexpected binding, too.
> >>
> >> AMD ACP digital + HDA analog headset microphone. If we follow the standard HDA
> >> behaviour, both inputs should trigger the mic LED. Two cards are in the game.
> > 
> > And that brings yet another question.  If the Dell privacy thing comes
> > to play here, for example, the mute LED is tied with the hardware
> > control of the built-in mic.  Then do we influence on this depending
> > on the headset mic mute state, too?
> 
> What users expect? I think that both scenarios are valid, thus we should allow
> them.

IMO, this is a hard part.  It's possible that user (or the system)
wants two different scenarios:
- LED indicates the built-in mic mute
- LED indicates the mute state of the currently used input

The current code assumes the latter case, and that might conflict with
the concept of Dell privacy stuff (as the built-in mic is still
allowed while using the headset).

How would be a good way to switch to a different scenario?


thanks,

Takashi