Re: [PATCH v1] ALSA: hda: cs35l41: Support mute notifications for CS35L41 HDA

[Stefan Binding <sbinding@opensource.cirrus.com>]

On 29/08/2023 15:23, Takashi Iwai wrote:
> On Tue, 29 Aug 2023 16:18:12 +0200,
> Stefan Binding wrote:
>>
>> On 25/08/2023 13:13, Takashi Iwai wrote:
>>> On Fri, 25 Aug 2023 14:05:25 +0200,
>>> Stefan Binding wrote:
>>>> From: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
>>>>
>>>> Some laptops require a hardware based mute system, where when a hotkey
>>>> is pressed, it forces the amp to be muted.
>>>>
>>>> For CS35L41, when the hotkey is pressed, an acpi notification is sent
>>>> to the CS35L41 Device Node. The driver needs to handle this notification
>>>> and call a _DSM function to retrieve the mute state.
>>>>
>>>> Since the amp is only muted during playback, the driver will only mute
>>>> or unmute if playback is occurring, otherwise it will save the mute
>>>> state for when playback starts.
>>>>
>>>> Only one handler can be registered for the acpi notification, but all
>>>> amps need to receive that notification, we can register a single handler
>>>> inside the Realtek HDA driver, so that it can then notify through the
>>>> component framework.
>>>>
>>>> Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
>>>> Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
>>> We don't do normally in this way.  The ACPI hot key handling is done
>>> via user-space, and user-space daemon triggers the mute of the
>>> system.
>>>
>>> Can't the ACPI notify the key event on those machines?
>> This feature is not the "normal" mute button on a keyboard, it is a
>> custom request
>> from a manufacturer which only mutes the audio on the speakers.
>> On previous generations, this was achieved using a GPIO controlled by
>> the BIOS/EC.
>> However, since CS35L41 does not have such GPIO, we must control it by
>> other means.
>>
>> Our solution, which we have to share with the Windows driver, it to use ACPI
>> notifications to tell the driver to mute the amps when the shortcut is
>> pressed.
>>
>> Does this seem like a valid exception to the typical approach?
> It's still the question whether we have to do this inevitably in the
> kernel in a way like that.  It sounds quite unusual.  Why this must be
> handled directly?  IOW, what's the difference from the "normal" mute
> button?
>
> And, even if we take this approach, it leaves the device muted without
> exposing it to user-space.  Then user wouldn't know what happens.
>
>
> thanks,
>
> Takashi
We spoke to the ODM for this system to get a more detailed explanation 
of this feature.
The keyboard shortcut enables something called "Unobtrusive Mode". 
According to their explanation:

- Unobtrusive mode is distinct to normal mute, as it only mutes the speakers
- There is no requirement to update the volume controls, as the screen 
backlight will be off anyway in this mode
- All other unobtrusive mode functions are enabled without user-space 
dependencies, and they would prefer not to make speaker mute an exception

Thanks,

Stefan