Re: [alsa-devel] [PATCH 0/2] add sysfs for acpi interfaces of thinkpad hardware mute
(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.
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.
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.
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.
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.
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.
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.
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?
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?
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.
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.
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
participants (3)
-
Arun Raghavan -
David Henningsson -
Matthew Garrett