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

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

[David Henningsson]

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


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

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

[Matthew Garrett]

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>

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

[David Henningsson]

On 08/14/2013 09:51 AM, Matthew Garrett wrote:
> 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.

You seem to know the history better than I do, but if there are
significant power savings or some faint noise removed (e g by turning an
amplifier off or so) by using the hardware mute, then it could still be
worth pursuing.

>> 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?

Yes, essentially. HDA has support for GPIOs, and HP on IDT codecs use
that to control LEDs. HP on Realtek codecs (not as common) use VREF
outputs on unused mic pins.

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

I see your point, but the question is what is more of a privacy guard
here. Do you expect USB mics and Bluetooth mics/headsets to be muted too?

If so, are you expecting some kind of kernel-wide block of recording,
including bluetooth, USB, and other sound cards? It does not sound like
a practical approach to me.

And if not, where do you draw the line and why?

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

To decide what the LEDs bind to is a design issue. I was thinking that
by giving control to userspace would give different
implementations/distros/etc the most freedom to do what design they wanted.

However, since, the hotkeys and the mutes are often very closely related
physically (e g the mute LED is physically located on the mute button),
I would expect them to follow each other. And the mute hotkey mutes the
current default PulseAudio output, so I'd expect the mic mute hotkey to
mute the current default PulseAudio input, and the LEDs to update
according to those mute states.

The privacy issue is interesting, but I don't see a practical way of
implementing things that would protect us against compromised userspaces.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

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

[Matthew Garrett]

On Wed, 2013-08-14 at 11:27 +0200, David Henningsson wrote:

> The privacy issue is interesting, but I don't see a practical way of
> implementing things that would protect us against compromised userspaces.

That's pretty easy - just tie the LED control to the HDA device in-kernel.

-- 
Matthew Garrett <matthew.garrett@nebula.com>

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

[David Henningsson]

On 08/14/2013 04:57 PM, Matthew Garrett wrote:
> On Wed, 2013-08-14 at 11:27 +0200, David Henningsson wrote:
> 
>> The privacy issue is interesting, but I don't see a practical way of
>> implementing things that would protect us against compromised userspaces.
> 
> That's pretty easy - just tie the LED control to the HDA device in-kernel.
> 

Well, my point was that the compromised userspace could still record
from other possibly connected microphones (such as USB or bluetooth
headsets).

But I guess one compromise could be to refuse userspace turn the mic
mute LED on, if the internal mic is unmuted.
Userspace would still be able to turn the mic mute LED off, to indicate
that recording can happen from other sources. It will be slightly more
complex for userspace though.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

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

[Matthew Garrett]

On Wed, 2013-08-14 at 21:53 +0200, David Henningsson wrote:
> On 08/14/2013 04:57 PM, Matthew Garrett wrote:
> > On Wed, 2013-08-14 at 11:27 +0200, David Henningsson wrote:
> > 
> >> The privacy issue is interesting, but I don't see a practical way of
> >> implementing things that would protect us against compromised userspaces.
> > 
> > That's pretty easy - just tie the LED control to the HDA device in-kernel.
> > 
> 
> Well, my point was that the compromised userspace could still record
> from other possibly connected microphones (such as USB or bluetooth
> headsets).

Ok, true. It'd need to be at a higher level than HDA to make this
consistent. But in theory, this is something that could be tied to the
full set of input sources.

> But I guess one compromise could be to refuse userspace turn the mic
> mute LED on, if the internal mic is unmuted.
> Userspace would still be able to turn the mic mute LED off, to indicate
> that recording can happen from other sources. It will be slightly more
> complex for userspace though.

Like I said, I don't think there's any reason for this to be in
userspace. If it's only going to represent the internal device, that's
trivial. If it's going to represent the global state of audio devices,
that's more complicated but doable. The only policy aspect is "What if I
want it to track the state of the currently selected audio device",
which just doesn't seem like a useful thing for it to do.

-- 
Matthew Garrett <matthew.garrett@nebula.com>

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

[David Henningsson]

On 08/14/2013 10:05 PM, Matthew Garrett wrote:
> On Wed, 2013-08-14 at 21:53 +0200, David Henningsson wrote:
>> On 08/14/2013 04:57 PM, Matthew Garrett wrote:
>>> On Wed, 2013-08-14 at 11:27 +0200, David Henningsson wrote:
>>>
>>>> The privacy issue is interesting, but I don't see a practical way of
>>>> implementing things that would protect us against compromised userspaces.
>>>
>>> That's pretty easy - just tie the LED control to the HDA device in-kernel.
>>>
>>
>> Well, my point was that the compromised userspace could still record
>> from other possibly connected microphones (such as USB or bluetooth
>> headsets).
> 
> Ok, true. It'd need to be at a higher level than HDA to make this
> consistent. But in theory, this is something that could be tied to the
> full set of input sources.

In theory perhaps, but in practice, I doubt it. USB audio perhaps,
because that's at least ALSA. Bluetooth uses its own stack (it's not
even ALSA), and I'm not sure how much of that stack is in the kernel.

And then we haven't considered other oddities such as FFADO, network
connected devices and what not...but perhaps we could leave those out?

>> But I guess one compromise could be to refuse userspace turn the mic
>> mute LED on, if the internal mic is unmuted.
>> Userspace would still be able to turn the mic mute LED off, to indicate
>> that recording can happen from other sources. It will be slightly more
>> complex for userspace though.
> 
> Like I said, I don't think there's any reason for this to be in
> userspace. If it's only going to represent the internal device, that's
> trivial. If it's going to represent the global state of audio devices,
> that's more complicated but doable. The only policy aspect is "What if I
> want it to track the state of the currently selected audio device",
> which just doesn't seem like a useful thing for it to do.

I say it's the *most* useful thing for it to do.

Imagine you're a non-technical user, who has never heard the words
"compromised userspace". You connect your headset where it fits (or
cordless), and then select the headset in sound settings (if it didn't
get selected for you when you plugged it in). You're on a VOIP call and
press the mic mute hotkey. Which mic did you expect to mute? The
selected one. On the mic mute hotkey button, there is also a LED. You
expect it to lit, because you muted the mic that you currently care
about, i e, the selected one.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

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

[Matthew Garrett]

On Wed, 2013-08-14 at 22:36 +0200, David Henningsson wrote:

> Imagine you're a non-technical user, who has never heard the words
> "compromised userspace". You connect your headset where it fits (or
> cordless), and then select the headset in sound settings (if it didn't
> get selected for you when you plugged it in). You're on a VOIP call and
> press the mic mute hotkey. Which mic did you expect to mute? The
> selected one. On the mic mute hotkey button, there is also a LED. You
> expect it to lit, because you muted the mic that you currently care
> about, i e, the selected one.

The user hit the mute key. Why would they expect *anything* to be
unmuted?

-- 
Matthew Garrett <matthew.garrett@nebula.com>

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

[David Henningsson]

On 08/14/2013 10:38 PM, Matthew Garrett wrote:
> On Wed, 2013-08-14 at 22:36 +0200, David Henningsson wrote:
> 
>> Imagine you're a non-technical user, who has never heard the words
>> "compromised userspace". You connect your headset where it fits (or
>> cordless), and then select the headset in sound settings (if it didn't
>> get selected for you when you plugged it in). You're on a VOIP call and
>> press the mic mute hotkey. Which mic did you expect to mute? The
>> selected one. On the mic mute hotkey button, there is also a LED. You
>> expect it to lit, because you muted the mic that you currently care
>> about, i e, the selected one.
> 
> The user hit the mute key. Why would they expect *anything* to be
> unmuted?
> 

Why should the userspace application, who just wants to lit a LED, have
to care about a lot of other sound cards and interfaces and mute them,
when the user does not care?

And what about multiseat setups? If a multiseat keyboard has a mic mute
LED, do you think another user's mic mute state should influence the LED
of your keyboard?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

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

[Matthew Garrett]

On Wed, 2013-08-14 at 22:59 +0200, David Henningsson wrote:
> On 08/14/2013 10:38 PM, Matthew Garrett wrote:
> > The user hit the mute key. Why would they expect *anything* to be
> > unmuted?
> > 
> 
> Why should the userspace application, who just wants to lit a LED, have
> to care about a lot of other sound cards and interfaces and mute them,
> when the user does not care?

Because there's no interface for the userspace application to light an
LED. Henrique has previously said that he doesn't want userspace to have
arbitrary control over it, and I agree with him.

> And what about multiseat setups? If a multiseat keyboard has a mic mute
> LED, do you think another user's mic mute state should influence the LED
> of your keyboard?

Once we see an external keyboard with a microphone mute LED, that's
certainly something we can worry about.

-- 
Matthew Garrett <matthew.garrett@nebula.com>

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

[David Henningsson]

On 08/14/2013 11:15 PM, Matthew Garrett wrote:
> On Wed, 2013-08-14 at 22:59 +0200, David Henningsson wrote:
>> On 08/14/2013 10:38 PM, Matthew Garrett wrote:
>>> The user hit the mute key. Why would they expect *anything* to be
>>> unmuted?
>>>
>>
>> Why should the userspace application, who just wants to lit a LED, have
>> to care about a lot of other sound cards and interfaces and mute them,
>> when the user does not care?
> 
> Because there's no interface for the userspace application to light an
> LED. Henrique has previously said that he doesn't want userspace to have
> arbitrary control over it, and I agree with him.

Trying to figure out the mute status of all the inputs is not an option,
due to the extreme diversity of audio hardware.

Having the LED follow the mute status of the internal mic is doable, but
IMO, it severely limits the usability of the LED.

I still think the better solution would be to let userspace handle it,
but anyway, this question is not thinkpad-acpi specific. So maybe we
need to make it a /sys/class/led then for the time being - that would at
least be a uniform interface.

>> And what about multiseat setups? If a multiseat keyboard has a mic mute
>> LED, do you think another user's mic mute state should influence the LED
>> of your keyboard?
> 
> Once we see an external keyboard with a microphone mute LED, that's
> certainly something we can worry about.

Well, a quick google search came up with this one [1]. But never mind -
this argument was just to show that the "mute status of all inputs" idea
is bad, and that's not happening anyway.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[1]
http://www.bloomberg.com/professional/files/2012/10/bloomberg_keyboard_2_installation_guide.pdf

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

[Arun Raghavan]

On Wed, 2013-08-14 at 07:51 +0000, Matthew Garrett wrote:
> 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.

The privacy concerns valid, but they're not insurmountable. You could
make userspace listen to the LED status and react as if the mute button
was pressed, making sure the two can never really go out of sync (just
an example off the top of my head).

Even if you don't do that, IMO it makes sense to expose the LEDs to
userspace. We're effectively talking about how the LEDs should behave as
an extension of the UI, and freezing the policy that governs that UI in
userspace is pretty inflexible.

-- Arun