On Fri, 23 Mar 2012, Matthew Garrett wrote: > I'm a little unenthusiastic about just pulling this in without working > out how userspace is going to consume it. It's a problem we may hit on > other devices as well, so we potentially need some sort of consistent > naming to indicate that it's a built-in mute LED. Hmm, I am not enthusiastic about exposing MIC leds for userspace to screw up at all. I'd rather expose an alsa mixer control that lets one mute/unmute the platform MIC, and have the kernel (if the platform doesn't do it already) enforce the LED to always be in the correct state. In my book, MICs getting enabled "stealthly" is something to be avoided on the design. However, I am not sure this platform interface exists on thinkpads (I do think there is something, though. Tracking the HKEY event on several DSDTs and looking at what it touches in the EC, plus some experiments should be able to give us a better picture). Exposing the LED for anyone who wants to play with it looked like a good compromise for the time being. Since it is not considered a "safe" led, it is not something that will be made generally available (requires a kconfig option to be set, which distros are not supposed to enable). I don't have anything against using a standard name, if such a thing exists though. But it would make a LOT more sense to have alsa provide a standard-named *trigger* that could be hooked to any LED and follows the MIC mute state of a mixer... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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
