There is an interesting use case that might make doing things at the
Alsa level limit functionality and it has to do with bluetooth & other
devices.
So let me give an external example. If you have an Android or iPhone and
you are making a phone call, when you press the microphone mute button
to mute your end of the line. This mute will apply for the handset,
loudspeaker, headphone mic, bluetooth headsets, & any other microphone
device (iphone has a ton of them).
Back to the Thinkpad. If the microphone mute light is just triggered via
Alsa .. you have a few issues:
- Which microphone are you mutting. At the AlSA level there is not
a clear way to mute them all. Also what if the microphones are not all
on the same sound device. But different sound devices. Even though
exposed through ALSA it's very difficult given the ALSA infrastructure
to say everything is muted.
- Bluetooth headsets are actually not exposed at the ALSA level if
you use Pulse Audio sound server. Pulse Audio exposes them.
End users will expect that if the light is on that ALL microphones are
muted to the machine.
Though by giving the power to the sound server (ex. Pulse Audio) it can
easily say mute all possible microphones.
Thanks,
Jerone
On Tue, 2011-11-08 at 22:43 -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 08 Nov 2011, Jerone Young wrote:
> > Is there a reason this is not a safe LED? It seems to fit with the on and
> > off capabilities of the other LEDS that are exposed through thinkpad-acpi.
> > Unlike speaker mute button, this does nothing in hardware.
>
> See my mail to alsa-devel, you were CC'd on it. I'd like to tie it to the
> mux state inside the kernel, and keep it unavailable to userspace. Not as
> good as a proper mic-mute implementation inside the EC, but better than
> depending on userspace to keep the LED state correct.
>
> > It ultimately is a userspace activity and it's userspace that makes sure
> > the LED is in a correct state for the user.
>
> Yeah, and that's el-cheap-o crap design (never mind it is what everyone else
> does), but hopefully we can make it better.
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
ibm-acpi-devel mailing list
ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
