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

[Takashi Iwai]

On Tue, 23 Mar 2021 23:49:40 +0100,
Dylan Reid wrote:
> 
> On Tue, Mar 23, 2021 at 2:40 PM Curtis Malainey <cujomalainey at google.com>
> wrote:
> 
>     On Mon, Mar 22, 2021 at 7:16 AM Jaroslav Kysela <perex at perex.cz> 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 ;-)
>     >
>     > Hi Sorry, i missed this was directly to dgreid and me. Will try to get
>     up
>     to speed on this.
> 
> Sorry, this one wasn't gmail's fault, it was my manual filtering of emails
> about LEDs:)
> 
> Chrome OS is supportive of user space control when possible. We will work with
> partners to establish a standard in Chrome OS for mute LED meaning (built in,
> headset, usb, etc). Having user space control allows different ecosystems to
> make different policy decisions. For us, the UCM-specified mute on/off will be
> driven exclusively by the audio daemon.

OK, thanks for a green signal.  So there doesn't seem any big concerns
about the implementation, so far.

Just to be sure, Mark, do you see any possible issues for Android and
other embedded deployment in this approach (sysfs + some init stuff +
UCM)?


Takashi