Hi, On 11/12/20 4:31 PM, Limonciello, Mario wrote: >>> Pressing the mute key activates a time delayed circuit to physically cut >>> off the mute. The LED is in the same circuit, so it reflects the true >>> state of the HW mute. The reason for the EC "ack" is so that software >>> can first invoke a SW mute before the HW circuit is cut off. Without SW >>> cutting this off first does not affect the time delayed muting or status >>> of the LED but there is a possibility of a "popping" noise leading to a >>> poor user experience. >> >> how long is that timeout ? > > The exact duration is controlled by component selection in the circuit. > Linux is typically able to respond faster than Windows in this case. > >> >>> Exposing as an LED device allows the codec drivers notification path to >>> EC ACK to work. >> >> Which driver exactly ? Who's gonna access this LED ? > > The flow is like this: > > 1) User presses key. HW does stuff with this key (timeout is started) > 2) Event is emitted from FW > 3) Event received by dell-privacy > 4) KEY_MICMUTE emitted from dell-privacy > 5) Userland picks up key and modifies kcontrol for SW mute > 6) Codec kernel driver catches and calls ledtrig_audio_set, like this: > > ledtrig_audio_set(LED_AUDIO_MICMUTE, rt715->micmute_led ? LED_ON : LED_OFF); > > 7) If "LED" is set to on dell-privacy notifies ec, and timeout is cancelled, > HW mic mute activated. > > Again, if anything in this flow doesn't happen HW mic mute is still activated, > just will take longer (for duration of timeout) and have popping noise. Thank you, can we put this in a comment in the driver please ? I guess this also means that the led_class device is just there to catch the ledtrig_audio_set() call so that dell-firmware can tell the EC that the sw-mute is done and that it can move ahead with the hw-mute. While the real, physical LED is fully under hardware control, right ? That should probably also be in the same comment in the driver (feel free to re-use part of my wording for that if that helps). Regards, Hans > >> >> >> --mtx >> >> -- >> --- >> Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert >> werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren >> GPG/PGP-Schlüssel zu. >> --- >> Enrico Weigelt, metux IT consult >> Free software and Linux embedded engineering >> info@xxxxxxxxx -- +49-151-27565287
