On Sat, May 14, 2011 at 11:47 AM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > On Sat, May 14, 2011 at 11:34:25AM -0400, Andy Lutomirski wrote: > >> It turns out that we can ask ACPI for one of three behaviors >> directly. They are "latch" (the default), "none" (no automatic >> control), and "toggle" (mute unmutes when muted). So we let the >> user control the mode through sysfs, and we don't generate KEY_MUTE >> in any mode other than "none". >> >> As an added bonus, we fix an old bug: the hardware mute control >> doesn't generate an ALSA change notification on newer ThinkPads. > > Which of these modes make sense for userspace? "none" sounds like it'd > be fine, except that the LED wouldn't work on new machines. So should we > just be setting "toggle" in all cases? The optimal situation would be > that we delete the OSI blacklist at the same time as we add this code. It's somewhat of a matter of preference. I think that on Windows on everything older than X220, pressing mute unconditionally mutes the sound, so it's a nice way to tell the system "don't make noise, regardless of what current settings are." On the X220, there's a dedicated mute indicator and the button toggles it. So if set "none" then we lose the use of the indicator and the ability to reliably mute the system without thought. The behavior I implemented reads the default from BIOS so that we do the right thing (or at least the thing that Lenovo intended) on all of these models unless the user writes something different to volume_autocontrol. (Disclaimer: I haven't actually tested the code on anything other than X220.) Later on, maybe we could convince PulseAudio to notice the mixer we expose and do something even nicer (like show a hardware mute OSD). --Andy ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
