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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <71808adb-bf54-a34b-5a63-70d454e3d426@opensource.cirrus.com>
Date:   Mon, 4 Sep 2023 13:00:20 +0100
From:   Stefan Binding <sbinding@...nsource.cirrus.com>
To:     Takashi Iwai <tiwai@...e.de>
CC:     Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
        <alsa-devel@...a-project.org>, <linux-kernel@...r.kernel.org>,
        <patches@...nsource.cirrus.com>,
        Vitaly Rodionov <vitalyr@...nsource.cirrus.com>
Subject: Re: [PATCH v1] ALSA: hda: cs35l41: Support mute notifications for
 CS35L41 HDA


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@...nsource.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@...nsource.cirrus.com>
>>>> Signed-off-by: Stefan Binding <sbinding@...nsource.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