On Wed, 2013-08-14 at 09:43 +0200, David Henningsson wrote:
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.
Sure. There was arguably a benefit in exposing the hardware mixer back in the *40 and earlier machines, since volume was also under hardware control back then. The mute support is somewhat vestigial, and I don't think trying to tie into it is going to make things better.
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.
HDA has support for mute LEDs that are tied to GPIO lines on the codec - is this the extent of it?
b) thinkpad-acpi currently uses custom sysfs nodes to control the LEDs.
Right.
c) and we also have the /sys/class/leds interface.
Yeah.
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.
I'm not convinced that should be our goal - if the mic mute light is on, I'd expect *all* mics to be muted, since the point of the light there is something of a privacy guard. It's not quite as clear that I'd expect the mute LED to bind to everything. However, given a single "currently selected sound card", there's no obviously user-visible difference between muting the current device and muting all devices.
Given the privacy concerns around the microphone LED, I think any exposed LED would have to be either under kernel control. Having a compromised component of a user session be able to record audio while leaving the LED lit would be a problem.