(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@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@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.