Re: [PATCH 0/2] add sysfs for acpi interfaces of thinkpad hardware mute

[Matthew Garrett <matthew.garrett@nebula.com>]

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@nebula.com>