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 -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
