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

[Takashi Iwai]

On Tue, 23 Mar 2021 10:38:46 +0100,
Takashi Iwai wrote:
> 
> On Mon, 22 Mar 2021 15:16:30 +0100,
> Jaroslav Kysela wrote:
> > 
> > Dne 20. 03. 21 v 10:48 Takashi Iwai napsal(a):
> > 
> > >> With other OS you mean e.g. Android?  Android has device-specific
> > >> init-scripts which can either call alsactl or directly do the
> > >> echo-s.
> > > 
> > > Also ChromeOS.  I'd like to get a general consensus before moving
> > > forward.
> > 
> > Where are ChromeOS people? They could join to the discussion which is floating
> > few months now. Perhaps, the gmail's spam filter does not allow them to
> > communicate with us ;-)
> 
> Also adding Dylan and Mark to Cc.
> 
> FYI, the patch set is:
>   https://lore.kernel.org/alsa-devel/20210317172945.842280-1-perex@perex.cz/

... and now back to the topic.

So the primary question is whether we want the sysfs entries to allow
user-space defining the mute-LED vs control binding externally.  With
this, the mute LED is supposed to be set up via udev rules that
triggers some alsactl stuff, and the rest is handled in an extension
in UCM profile.  If this approach is acceptable on all platforms, we
can go for it.  That was the question to other platforms like Android
and ChromeOS.


And, now looking into the details, I have a few more questions:

- The binding with SNDRV_CTL_ELEM_* bit flag is handy for some drivers
  but not for everything; e.g. if we want to add the binding in ASoC
  machine driver, an API like
    snd_ctl_bind_mute_led(card, elem_id, inverted);
  would be easier.  It'd be essentially an internal call of the sysfs
  binding.  (I haven't checked, but might this be also more
  straightforward conversion for HD-audio case, too?)

- The binding in the kernel could (should?) be shown in the sysfs
  output.  Currently it seems handled differently?

- Specifying the numid may the code simpler in kernel side?
  alsactl has already the string parser.

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


thanks,

Takashi