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. -- Matthew Garrett <matthew.garrett@xxxxxxxxxx> ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
