Dne 23. 03. 21 v 12:34 Takashi Iwai napsal(a):
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?
[Adding Perry /Dell/ to the discussion]
It's an user space setup. We can manage some conditional settings in UCM and the shell scripts can be written with conditional parts. Perhaps, a global configuration file(s) in /etc/alsa may specify the requested scenario.
I would just start with a default behavior (which may be hw specific) and refine this later.
Jaroslav