[alsa-devel] [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