(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@xxxxxxxxxx> 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@xxxxxxxxxx> > > > 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 -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
