Fix mute key on older Lenovo made Thinkpads by OSI blacklisting

After much discussion over these patches there are some points that have been sorted out:

- New X & W series Thinkpads (X201 & W510) ONLY send a mute key press and nothing more. By adding the older models, as this patch does, has the machines acting with the same behavior. Lenovo has dropped hardware mute. Lenovo looks to not be updating the R series.

- These models have no light indicator on them that the mute is on. This is a Lenovo x200 keyboard:
http://www.slashgear.com/gallery/data_files/7/4/ThinkPad_X200_keyboard.jpg

- These machines do not send any ACPI or any type of event when the mute button is pressed. Unless you expose to them that Linux is the OS. Then it will send mute key press. Lenovo made Thinkpads do not have the same behavior as the IBM made Thinkpads.

- While the hardware mute is disabled by this patch.
- Fixes muting of headphone jack. Lenovo only has hardware mute wired to the external speakers.
- Gives users a much better Linux experience as Linux can see the mute keypress and so (in distributions like Ubuntu), give users visual indication that Mute is on. Right now users have no idea.

* The hardware mute muted the volume in the hardware, not waiting for software. This only comes in handy if userspace or kernel crashes or malfunctions and sound is still being sent from the sound card. Thought this is a rare case. Most users perfer knowing that the mute is on or off.

- To pull off hardware muting properly under Linux will require a userspace daemon to keep both hardware mute & userspace sound servers in sync. Again this is something newer equivalent Thinkpads could not use.

- Other Lenovo models from this exact same time frame are already in blacklist.c fixing the SAME issue, and they ALL change the behavior in the SAME way. These include Lenovo Thinkpads T400 & T500.

- This has been tested by many many users who love this behavior over the way it works now. Lenovo has changed the default behavior of the new Thinkpads to reflect this.

- These machines will not be getting a bios update to change the behavior in the future.

This patch fixes that mute keys for X & R & W series Thinkpads. For these Thinkpads in the BIOS if OS exposes itself as "Linux" it will switch the functionality of the mute key to send a mute key press to the OS. These machines will not be getting any bios updates in the future.

All of these Thinkpads do not have a little light that would indicate the mute is on. So having them send the mute key to the OS makes a better user experience and also will match behavior of newer Thinkpads. These all have the same quirk the T400 & T500 have.

Unlike the last time I sent a similar patch(s) somethings have happened:

- All new Lenovo Thinkpads now send a mute key press to the OS by default (x201 series).

- I've decoded the bioses. Under the Linux selection it only does one operation. Switch the hardware mute to a software mute. Has no special operations done under Windows selections.

- On all the machines. The hardware mute key is only wired to the external speakers. So the headphone jack does not get muted by the hardware mute.

- I also have gotten confirmation from users around the net that it works. Except for the W700, though based on data I found it was the same as the W500.

index 2815df6..cce6e1a 100644
@@ -285,6 +285,46 @@ static struct dmi_system_id acpi_osi_dmi_table[]

__initdata = {
                     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T500"),
                },
        },
+       {
+       .callback = dmi_enable_osi_linux,
+       .ident = "Lenovo ThinkPad X200[s][t]",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+                    DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X200"),
+               },
+       },
+       {
+       .callback = dmi_enable_osi_linux,
+       .ident = "Lenovo ThinkPad R400",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+                    DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad R400"),
+               },
+       },
+       {
+       .callback = dmi_enable_osi_linux,
+       .ident = "Lenovo ThinkPad R500",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+                    DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad R500"),
+               },
+       },
+       {
+       .callback = dmi_enable_osi_linux,
+       .ident = "Lenovo ThinkPad W500",
+       .matches = {
+                   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+                   DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W500"),
+               },
+       },
+       {
+       .callback = dmi_enable_osi_linux,
+       .ident = "Lenovo ThinkPad W700[ds]",
+       .matches = {

+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W700"),
+ },
+ },

        {}

};

Hello Jerone,

Thanks for working to make Linux users with these systems happier.

As you know, we really really hate to add OSI(Linux) hooks because the OSI string "Linux" is not an appropriate OSI string as it doesn't describe a single interface, or even version of Linux...

Thus in the upstream kernel, we have shipped with OSI(Linux) disabled since 2.6.23.

The risk of restoring OSI(Linux) is that BIOS writers will not realize that they have a BIOS bug when they use it and the abuse and risk of bugs will become unbounded.

Of course for systems that have shipped already, the damage is done -- and that seems to be the case here.

So the question I have is if OSI(Linux) *only* changes the mute button on these boxes, or if it has any other effects. Generally we need to examine the DSDT for each box to know. Do you have the DSDT's for these boxes?

thanks,
Len Brown, Intel Open Source Technology Center

thanks for the DSDT for the x200 and x301.
In these two cases, the OSI(Linux) workaround looks isolated, and thus relatively safe.

I've applied your patch to the ACPI test branch, and I'm inclined to push it with 2.6.35 with the justification that it is consistent with our current DMI entries to fix thinkpad mute button on other models.

Matthew, Henrique,
If you'd like to talk me out of this, now is your chance:-)

thanks,
Len Brown, Intel Open Source Technology Center

Both the x200 and x301 DSDT do this:

              If (CondRefOf (\_OSI, Local0))
                {
                    If (\_OSI ("Windows 2001"))
                    {
                        Store (0x01, \WNTF)
                        Store (0x01, \WXPF)
                        Store (0x00, \WSPV)
                    }

                    If (\_OSI ("Windows 2001 SP1"))
                    {
                        Store (0x01, \WSPV)
                    }

                    If (\_OSI ("Windows 2001 SP2"))
                    {
                        Store (0x02, \WSPV)
                    }

                    If (\_OSI ("Windows 2006"))
                    {
                        Store (0x01, \WVIS)
                    }

                    If (\_OSI ("Windows 2009"))
                    {
                        Store (0x01, \WIN7)
                    }

                    If (\_OSI ("Linux"))
                    {
                        Store (0x01, \LNUX)
                    }

The important thing here is that OSI(Linux)
doesn't disable any of the windows compatibility
flags above as it does in some other DSDTs.

                    If (\_OSI ("FreeBSD"))
                    {
                        Store (0x01, \LNUX)
                    }

and this _INI-time check is the only effect of LNUX:

            If (\LNUX)
            {
                \_SB.PCI0.LPC.EC.SAUM (0x02)
                \UCMS (0x1C)
            }

Of course SAUM pokes the EC and UCMS is an SMI wrapper, so we don't really know all they may do; but at least OSI(Linux) doesn't obviously disable the concept of windows compatibility in this BIOS, and checks for LNUX are limited to init-time.

SAUM tells the EC to change the keyboard/event filter (at the very least, one would have to ask Lenovo to know for sure). UCMS (0x1C) tells the BIOS to change operating mode as well, probably to match whatever SAUM asked of the EC.

As far as anyone knows, it is indeed restricted to the behaviour of the audio keys.

  "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