[alsa-devel] [PATCH 0/2] add sysfs for acpi interfaces of thinkpad hardware mute

[David Henningsson]

(Added alsa-devel to CC)

On 08/14/2013 09:16 AM, Alex Hung wrote:
> Added in David and Tim who also has some ideas to share.
> 
> On Wed, Aug 14, 2013 at 3:00 PM, Matthew Garrett
> <matthew.garrett at nebula.com> wrote:
>> On Wed, 2013-08-14 at 14:41 +0800, Alex Hung wrote:
>>> Hi Matthew,
>>>
>>> The problem is that thinkpad-acpi does not aware of mute is changed by
>>> either hotkey presses or in desktop.
>>
>> Ok, how about this. Register the LED with the kernel LED subsystem. Add
>> a new LED trigger for volume-mute. Have the HDA driver call that trigger
>> whenever the mute state changes.
>>
>> --
>> Matthew Garrett <matthew.garrett at nebula.com>
> 
> 
> 

So, to take a wider grip on this issue.

First, the hardware mute. Because this is directly connected to the
internal speaker (and headphones?), it needs to turn into a ALSA
kcontrol on the sound card that controls speaker and/or headphones. And
it needs to named accordingly, e g "Speaker Playback Switch" if it
controls the speaker only.
Exactly how this is going to work out given the arbitrary module load
order of snd-hda-intel and thinkpad-acpi, I'm not sure, but the way of
creating another sound card (which I've seen on some thinkpads) just
isn't working out for userspace.

Second, about the mute LEDs and mic-mute LEDs, we currently have several
interfaces to choose from:
 a) HP LEDs currently uses a ALSA kcontrol to control them. For Mute LED
there is also a limited automatic control of this LED from kernel space
(by default), so it follows the status of "Master Playback Switch" IIRC.
 b) thinkpad-acpi currently uses custom sysfs nodes to control the LEDs.
 c) and we also have the /sys/class/leds interface.
There might be even more solutions.

It's important we get a consistent interfaces towards userspace for the
LEDs. And we should also make sure we don't have a permissions problem:
if we want the mute/mic-mute LED to follow the status of the currently
selected sound card in PulseAudio, which IMO should be our goal, writes
cannot be root-only.
To have the HDA driver call into the LED subsystem is better than
nothing, but in the end we would want the LEDs to follow whatever sound
input/output the user currently uses, whether that is bluetooth, USB,
HDMI, or internal audio.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic