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 -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
