[alsa-devel] [PATCH 0/2] Disable the ThinkPad HW mute/level control when possible
This series is being resurrected after several years, and it's quite different from before, so I'm restarting the version number at 1 :)
ThinkPad volume and mute controls are a mess. For whatever reason, ThinkPads have mute buttons that send KEY_MUTE *and* control an invisible-to-ALSA mute switch. Some of them have volume controls that interact with this switch as well.
This is a perennial source of problems. On most ThinkPads, if you press mute and then unmute using GUI controls, you have no sound, because userspace and ALSA state gets out of sync with the hardware switch. There's a separate "sound card" that exposes the hardware switch, but userspace code generally doesn't understand that.
There are already a few _OSI(Linux) overrides to turn all the hardware buttons into regular buttons. Rather than quirking ACPI everywhere, just teach thinkpad-acpi to program the buttons for full software control and to disable hardware controls. That allows us to remove the ACPI quirks and have normal mute controls. This approach should be much simpler than adding even more kludgey ALSA integration for questionable gain.
I haven't tested on my X220 (which has a mute light in addition to a mute button), since that laptop's SATA controller died last week. It should work, though, and if someone else could test this on a ThinkPad with a mute light, that would be great.
Andy Lutomirski (2): thinkpad-acpi: Try to use full software mute control acpi: Remove _OSI(Linux) for ThinkPads
drivers/acpi/blacklist.c | 54 ------------------ drivers/platform/x86/thinkpad_acpi.c | 107 +++++++++++++++++++++++++++++++---- 2 files changed, 97 insertions(+), 64 deletions(-)
From: Andy Lutomirski luto@MIT.EDU
ThinkPads have hardware volume controls and three buttons to control them. (These are separate from the standard mixer.) By default, the buttons are:
- Mute: Mutes the hardware volume control and generates KEY_MUTE. - Up: Unmutes, generates KEY_VOLUMEUP, and increases volume if applicable. (Newer thinkpads only have hardware mute/unmute.) - Down: Unmutes, generates KEY_VOLUMEDOWN, and decreases volume if applicable.
This behavior is unfortunate, since modern userspace will also handle the hotkeys and change the other mixer. If the software mixer is muted and the hardware mixer is unmuted and you push mute, hilarity ensues as they both switch state.
Rather than adding a lot of complex ALSA integration to fix this, just disable the special ThinkPad volume controls when possible. This turns the mute and volume buttons into regular buttons, and standard software controls will work as expected.
ALSA already knows about the mute light on models with a mute light, so everything should just work.
This should also allow us to remove _OSI(Linux) for all ThinkPads.
For future reference: It turns out that we can ask ACPI for one of three behaviors directly on very new models. They are "latch" (the default), "none" (no automatic control), and "toggle" (mute unmutes when muted). All of the modes besides "none" seem to be a bit buggy, though, and there is no known way to get any notification that the hardware state has changed other than listening for a mute button press on the i8042 port.
Signed-off-by: Andy Lutomirski luto@mit.edu --- drivers/platform/x86/thinkpad_acpi.c | 107 +++++++++++++++++++++++++++++++---- 1 file changed, 97 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index 3bbc6eb60de5..9c8e17ec4b14 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -6559,6 +6559,16 @@ static struct ibm_struct brightness_driver_data = { * bits 3-0 (volume). Other bits in NVRAM may have other functions, * such as bit 7 which is used to detect repeated presses of MUTE, * and we leave them unchanged. + * + * The EC or perhaps SMM firmware can optionally automatically change + * the volume in response to user input. Unfortunately, this rarely + * works well. The laptop changes the state of its internal MUTE gate + * *and* sends KEY_MUTE, causing any user code that responds to the mute + * button to get confused. The hardware MUTE gate is also unnecessary, + * since user code can handle the mute button without kernel or EC help. + * + * To avoid confusing userspace, we simply disable all EC-based mute + * and volume controls when possible. */
#ifdef CONFIG_THINKPAD_ACPI_ALSA_SUPPORT @@ -6613,11 +6623,20 @@ enum tpacpi_volume_capabilities { TPACPI_VOL_CAP_MAX };
+enum tpacpi_mute_btn_mode { + TP_EC_MUTE_BTN_LATCH = 0, /* Mute mutes; up/down unmutes */ + /* We don't know what mode 1 is. */ + TP_EC_MUTE_BTN_NONE = 2, /* Mute and up/down are just keys */ + TP_EC_MUTE_BTN_TOGGLE = 3, /* Mute toggles; up/down unmutes */ +}; + static enum tpacpi_volume_access_mode volume_mode = TPACPI_VOL_MODE_MAX;
static enum tpacpi_volume_capabilities volume_capabilities; static bool volume_control_allowed; +static bool software_mute_requested = true; +static bool software_mute_active;
/* * Used to syncronize writers to TP_EC_AUDIO and @@ -6635,6 +6654,8 @@ static void tpacpi_volume_checkpoint_nvram(void) return; if (!volume_control_allowed) return; + if (software_mute_active) + return;
vdbg_printk(TPACPI_DBG_MIXER, "trying to checkpoint mixer state to NVRAM...\n"); @@ -6696,6 +6717,12 @@ static int volume_set_status_ec(const u8 status)
dbg_printk(TPACPI_DBG_MIXER, "set EC mixer to 0x%02x\n", status);
+ /* + * On X200s, and possibly on others, it can take a while for + * reads to become correct. + */ + msleep(1); + return 0; }
@@ -6778,6 +6805,38 @@ unlock: return rc; }
+static int volume_set_software_mute(bool verbose) +{ + int rc = 0; + int result; + + if (mutex_lock_killable(&volume_mutex) < 0) + return -EINTR; + + if (verbose) { + if (!acpi_evalf(ec_handle, &result, "HAUM", "qd")) + return -EIO; + + dbg_printk(TPACPI_DBG_INIT | TPACPI_DBG_MIXER, + "Initial HAUM setting was %d\n", + result); + } + + if (!acpi_evalf(ec_handle, &result, "SAUM", "qdd", + (int)TP_EC_MUTE_BTN_NONE)) { + rc = -EIO; + goto out; + } + + if (result != TP_EC_MUTE_BTN_NONE) + pr_warn("thinkpad_acpi: Unexpected SAUM result %d\n", + result); + +out: + mutex_unlock(&volume_mutex); + return rc; +} + static int volume_alsa_set_volume(const u8 vol) { dbg_printk(TPACPI_DBG_MIXER, @@ -6885,7 +6944,12 @@ static void volume_suspend(void)
static void volume_resume(void) { - volume_alsa_notify_change(); + if (software_mute_active) { + if (volume_set_software_mute(false) < 0) + pr_warn("thinkpad_acpi: failed to restore software mute\n"); + } else { + volume_alsa_notify_change(); + } }
static void volume_shutdown(void) @@ -7004,6 +7068,8 @@ static const struct tpacpi_quirk volume_quirk_table[] __initconst = { .quirks = TPACPI_VOL_Q_MUTEONLY } };
+static int volume_write(char *buf); + static int __init volume_init(struct ibm_init_struct *iibm) { unsigned long quirks; @@ -7085,16 +7151,33 @@ static int __init volume_init(struct ibm_init_struct *iibm) "mute is supported, volume control is %s\n", str_supported(!tp_features.mixer_no_level_control));
- rc = volume_create_alsa_mixer(); - if (rc) { - pr_err("Could not create the ALSA mixer interface\n"); - return rc; - } + if (software_mute_requested && volume_set_software_mute(true) == 0) { + char unmute_cmd[] = "unmute,level 14"; /* must be non-const */ + BUILD_BUG_ON(TP_EC_VOLUME_MAX != 14); + + software_mute_active = true; + + /* + * In software mute mode, the standard codec controls + * take precendence, so we unmute the ThinkPad HW switch + * at startup. Just on case there are SAUM-capable + * ThinkPads with level controls, set max HW volume as + * well. + */ + if (volume_write(unmute_cmd) != 0) + pr_warn("Failed to unmute ThinkPad HW\n"); + } else { + rc = volume_create_alsa_mixer(); + if (rc) { + pr_err("Could not create the ALSA mixer interface\n"); + return rc; + }
- pr_info("Console audio control enabled, mode: %s\n", - (volume_control_allowed) ? - "override (read/write)" : - "monitor (read only)"); + pr_info("Console audio control enabled, mode: %s\n", + (volume_control_allowed) ? + "override (read/write)" : + "monitor (read only)"); + }
vdbg_printk(TPACPI_DBG_INIT | TPACPI_DBG_MIXER, "registering volume hotkeys as change notification\n"); @@ -9091,6 +9174,10 @@ MODULE_PARM_DESC(volume_control, "Enables software override for the console audio " "control when true");
+module_param_named(software_mute, software_mute_requested, bool, 0444); +MODULE_PARM_DESC(software_mute, + "Request full software mute control"); + /* ALSA module API parameters */ module_param_named(index, alsa_index, int, 0444); MODULE_PARM_DESC(index, "ALSA index for the ACPI EC Mixer");
On Thu, 16 Oct 2014, Andy Lutomirski wrote:
ThinkPads have hardware volume controls and three buttons to control them. (These are separate from the standard mixer.) By default, the buttons are:
- Mute: Mutes the hardware volume control and generates KEY_MUTE.
- Up: Unmutes, generates KEY_VOLUMEUP, and increases volume if applicable. (Newer thinkpads only have hardware mute/unmute.)
- Down: Unmutes, generates KEY_VOLUMEDOWN, and decreases volume if applicable.
On IBM ThinkPads, the "generates KEY_foo" thing is controlable by the driver. In fact, thinkpad_acpi defaults to NOT send these, all breakage is entirely the fault of userspace that enables it instead of doing OSD out of the extra mixer, and then fails to deal with the side-effects.
On Lenovo ThinkPads, it depends on BIOS/EC version for the X60/T60. Later versions will behave like the X61/T61. Since family 200 you can tell the EC to switch modes (latch, toggle, none), but Lenovo didn't test it well enough.
This behavior is unfortunate, since modern userspace will also handle the hotkeys and change the other mixer. If the software
Like I said, we disable that by default, and userspace enables them back because they want to use it as a keyboard. We could override it entirely on the IBM thinkpads, and refuse to issue any key events no matter what, I suppose.
This should also allow us to remove _OSI(Linux) for all ThinkPads.
No, it doesn't. Only after an exaustive search for what _OSI(Linux) changes across a brickload of thinkpad ACPI dumps could we say that for sure.
For future reference: It turns out that we can ask ACPI for one of three behaviors directly on very new models. They are "latch" (the default), "none" (no automatic control), and "toggle" (mute unmutes when muted). All of the modes besides "none" seem to be a bit buggy, though, and there is no known way to get any notification that the hardware state has changed other than listening for a mute button press on the i8042 port.
Yeah.
- The EC or perhaps SMM firmware can optionally automatically change
- the volume in response to user input. Unfortunately, this rarely
It is the EC, which also emulates the i8042 KBC.
I don't see any problems with the code, will have to test it in a IBM thinkpad, though (I have one).
On Thu, Oct 16, 2014 at 11:31 AM, Henrique de Moraes Holschuh hmh@hmh.eng.br wrote:
On Thu, 16 Oct 2014, Andy Lutomirski wrote:
ThinkPads have hardware volume controls and three buttons to control them. (These are separate from the standard mixer.) By default, the buttons are:
- Mute: Mutes the hardware volume control and generates KEY_MUTE.
- Up: Unmutes, generates KEY_VOLUMEUP, and increases volume if applicable. (Newer thinkpads only have hardware mute/unmute.)
- Down: Unmutes, generates KEY_VOLUMEDOWN, and decreases volume if applicable.
On IBM ThinkPads, the "generates KEY_foo" thing is controlable by the driver. In fact, thinkpad_acpi defaults to NOT send these, all breakage is entirely the fault of userspace that enables it instead of doing OSD out of the extra mixer, and then fails to deal with the side-effects.
Are you sure? I'm reasonably confident that the KEY_MUTE comes from i8042, not from an ACPI GPE. Even without this patch, pressing the mute button sends KEY_MUTE. Maybe there's a control I missed, but if we turn off KEY_MUTE, then I don't know how we'd be notified at all that the HW mixer changed state. (In any case, with this patch, everything seems to work.)
On Lenovo ThinkPads, it depends on BIOS/EC version for the X60/T60. Later versions will behave like the X61/T61. Since family 200 you can tell the EC to switch modes (latch, toggle, none), but Lenovo didn't test it well enough.
"none" seems to work well on all ThinkPads that I've tried. The other modes seem to have spotty support.
This behavior is unfortunate, since modern userspace will also handle the hotkeys and change the other mixer. If the software
Like I said, we disable that by default, and userspace enables them back because they want to use it as a keyboard. We could override it entirely on the IBM thinkpads, and refuse to issue any key events no matter what, I suppose.
How? The only way I ever found to do that was using the i8042_filter in the older incarnations of this driver, and that was incredibly complex, added little obvious value, and *still* didn't give a fully consistent UI, since userspace doesn't understand the extra thinkpad mixer.
This should also allow us to remove _OSI(Linux) for all ThinkPads.
No, it doesn't. Only after an exaustive search for what _OSI(Linux) changes across a brickload of thinkpad ACPI dumps could we say that for sure.
I think we only need that for the four models in question. Also, all the commit messages for those quirk additions seem to suggest that they were done to improve volume controls. And I'm pretty sure I already checked at least one of those models (that's how I discovered HAUM/SAUM in the first place).
Anyway, patch 2 is optional.
For future reference: It turns out that we can ask ACPI for one of three behaviors directly on very new models. They are "latch" (the default), "none" (no automatic control), and "toggle" (mute unmutes when muted). All of the modes besides "none" seem to be a bit buggy, though, and there is no known way to get any notification that the hardware state has changed other than listening for a mute button press on the i8042 port.
Yeah.
- The EC or perhaps SMM firmware can optionally automatically change
- the volume in response to user input. Unfortunately, this rarely
It is the EC, which also emulates the i8042 KBC.
I don't see any problems with the code, will have to test it in a IBM thinkpad, though (I have one).
Please test v2 instead. :)
--Andy
-- "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
On Thu, 16 Oct 2014, Andy Lutomirski wrote:
On IBM ThinkPads, the "generates KEY_foo" thing is controlable by the driver. In fact, thinkpad_acpi defaults to NOT send these, all breakage is entirely the fault of userspace that enables it instead of doing OSD out of the extra mixer, and then fails to deal with the side-effects.
Are you sure? I'm reasonably confident that the KEY_MUTE comes from
Yes.
i8042, not from an ACPI GPE. Even without this patch, pressing the
The EC *is* the i8042 in a ThinkPad. Really. You talk to the same chip and to the same firmware over the ACPI EC ports, the i8042 ports, and the Renesas extra LPC3 channel (used by HDAPS and SBS).
That said, on a **IBM** ThinkPad, _nothing_ related to the digital volume control comes from the i8042 port. In fact, with older BIOSes, you couldn't even get it from ACPI unless you hooked the GPE directly because the required ACPI L/E methods were missing and were added by later versions of the T4x/R4x/X3x BIOS.
The EC firmware in a thinkpad is often more capable than what the BIOS exposes.
KEY_MUTE comes from the i8042 in Lenovo Thinkpads, only. And they started doing that when they removed the hardware volume control chip. It was retrofitted in later versions of the T60 BIOS (v2.x), I don't know how well though.
On Lenovo ThinkPads, it depends on BIOS/EC version for the X60/T60. Later versions will behave like the X61/T61. Since family 200 you can tell the EC to switch modes (latch, toggle, none), but Lenovo didn't test it well enough.
"none" seems to work well on all ThinkPads that I've tried. The other modes seem to have spotty support.
I am fine that we go with "none" and emulate everything in the driver where supported, yes.
This behavior is unfortunate, since modern userspace will also handle the hotkeys and change the other mixer. If the software
Like I said, we disable that by default, and userspace enables them back because they want to use it as a keyboard. We could override it entirely on the IBM thinkpads, and refuse to issue any key events no matter what, I suppose.
How? The only way I ever found to do that was using the i8042_filter in the older incarnations of this driver, and that was incredibly
You didn't try it on a IBM thinkpad, just on Lenovo thinkpads, then...
This should also allow us to remove _OSI(Linux) for all ThinkPads.
No, it doesn't. Only after an exaustive search for what _OSI(Linux) changes across a brickload of thinkpad ACPI dumps could we say that for sure.
I think we only need that for the four models in question. Also, all the commit messages for those quirk additions seem to suggest that they were done to improve volume controls. And I'm pretty sure I already checked at least one of those models (that's how I discovered HAUM/SAUM in the first place).
Anyway, patch 2 is optional.
Since you did due diligency, I'm fine with that. It is already in a separate patch, so it is easy to bissect and revert anyway.
- The EC or perhaps SMM firmware can optionally automatically change
- the volume in response to user input. Unfortunately, this rarely
It is the EC, which also emulates the i8042 KBC.
I don't see any problems with the code, will have to test it in a IBM thinkpad, though (I have one).
Please test v2 instead. :)
I will only be able to do that during the weekend anyway, so feel free to send a v3 if you need :-)
On Thu, Oct 16, 2014 at 11:54 AM, Henrique de Moraes Holschuh hmh@hmh.eng.br wrote:
On Thu, 16 Oct 2014, Andy Lutomirski wrote:
On IBM ThinkPads, the "generates KEY_foo" thing is controlable by the driver. In fact, thinkpad_acpi defaults to NOT send these, all breakage is entirely the fault of userspace that enables it instead of doing OSD out of the extra mixer, and then fails to deal with the side-effects.
Are you sure? I'm reasonably confident that the KEY_MUTE comes from
Yes.
i8042, not from an ACPI GPE. Even without this patch, pressing the
The EC *is* the i8042 in a ThinkPad. Really. You talk to the same chip and to the same firmware over the ACPI EC ports, the i8042 ports, and the Renesas extra LPC3 channel (used by HDAPS and SBS).
Huh, interesting. That makes sense.
That said, on a **IBM** ThinkPad, _nothing_ related to the digital volume control comes from the i8042 port. In fact, with older BIOSes, you couldn't even get it from ACPI unless you hooked the GPE directly because the required ACPI L/E methods were missing and were added by later versions of the T4x/R4x/X3x BIOS.
The EC firmware in a thinkpad is often more capable than what the BIOS exposes.
KEY_MUTE comes from the i8042 in Lenovo Thinkpads, only. And they started doing that when they removed the hardware volume control chip. It was retrofitted in later versions of the T60 BIOS (v2.x), I don't know how well though.
So the question is: are there IBM models (or models that don't send KEY_MUTE, anyway) that nonetheless expose HAUM and SAUM? If not, then my patch should be okay. If so, we'll need further filtering.
On Lenovo ThinkPads, it depends on BIOS/EC version for the X60/T60. Later versions will behave like the X61/T61. Since family 200 you can tell the EC to switch modes (latch, toggle, none), but Lenovo didn't test it well enough.
"none" seems to work well on all ThinkPads that I've tried. The other modes seem to have spotty support.
I am fine that we go with "none" and emulate everything in the driver where supported, yes.
This behavior is unfortunate, since modern userspace will also handle the hotkeys and change the other mixer. If the software
Like I said, we disable that by default, and userspace enables them back because they want to use it as a keyboard. We could override it entirely on the IBM thinkpads, and refuse to issue any key events no matter what, I suppose.
How? The only way I ever found to do that was using the i8042_filter in the older incarnations of this driver, and that was incredibly
You didn't try it on a IBM thinkpad, just on Lenovo thinkpads, then...
I'm not sure I ever owned an IBM thinkpad. I used Acer back then, and my next laptop is quite likely to be
This should also allow us to remove _OSI(Linux) for all ThinkPads.
No, it doesn't. Only after an exaustive search for what _OSI(Linux) changes across a brickload of thinkpad ACPI dumps could we say that for sure.
I think we only need that for the four models in question. Also, all the commit messages for those quirk additions seem to suggest that they were done to improve volume controls. And I'm pretty sure I already checked at least one of those models (that's how I discovered HAUM/SAUM in the first place).
Anyway, patch 2 is optional.
Since you did due diligency, I'm fine with that. It is already in a separate patch, so it is easy to bissect and revert anyway.
- The EC or perhaps SMM firmware can optionally automatically change
- the volume in response to user input. Unfortunately, this rarely
It is the EC, which also emulates the i8042 KBC.
I don't see any problems with the code, will have to test it in a IBM thinkpad, though (I have one).
Please test v2 instead. :)
I will only be able to do that during the weekend anyway, so feel free to send a v3 if you need :-)
-- "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
On Thu, 16 Oct 2014, Andy Lutomirski wrote:
On Thu, Oct 16, 2014 at 11:54 AM, Henrique de Moraes Holschuh hmh@hmh.eng.br wrote: So the question is: are there IBM models (or models that don't send KEY_MUTE, anyway) that nonetheless expose HAUM and SAUM? If not, then my patch should be okay. If so, we'll need further filtering.
No, these were introduced in the X61/T61. Still, the standard paranoia applies, and you should check for HAUM/SAUM only on VENDOR_LENOVO, and assume they don't exist (because if they do, they are something else) for VENDOR_IBM.
On Thu, Oct 16, 2014 at 12:58 PM, Henrique de Moraes Holschuh hmh@hmh.eng.br wrote:
On Thu, 16 Oct 2014, Andy Lutomirski wrote:
On Thu, Oct 16, 2014 at 11:54 AM, Henrique de Moraes Holschuh hmh@hmh.eng.br wrote: So the question is: are there IBM models (or models that don't send KEY_MUTE, anyway) that nonetheless expose HAUM and SAUM? If not, then my patch should be okay. If so, we'll need further filtering.
No, these were introduced in the X61/T61. Still, the standard paranoia applies, and you should check for HAUM/SAUM only on VENDOR_LENOVO, and assume they don't exist (because if they do, they are something else) for VENDOR_IBM.
Done in v3.
My X220 seems to be alive again for the time being -- I suspect that there's a marginal connection somewhere. It seems to be fully functional with this match, and the mute light works as expected (thanks, Takashi et al!).
--Andy
On Thu, Oct 16, 2014 at 11:54 AM, Henrique de Moraes Holschuh hmh@hmh.eng.br wrote:
On Thu, 16 Oct 2014, Andy Lutomirski wrote:
On IBM ThinkPads, the "generates KEY_foo" thing is controlable by the driver. In fact, thinkpad_acpi defaults to NOT send these, all breakage is entirely the fault of userspace that enables it instead of doing OSD out of the extra mixer, and then fails to deal with the side-effects.
Are you sure? I'm reasonably confident that the KEY_MUTE comes from
Yes.
i8042, not from an ACPI GPE. Even without this patch, pressing the
The EC *is* the i8042 in a ThinkPad. Really. You talk to the same chip and to the same firmware over the ACPI EC ports, the i8042 ports, and the Renesas extra LPC3 channel (used by HDAPS and SBS).
That said, on a **IBM** ThinkPad, _nothing_ related to the digital volume control comes from the i8042 port. In fact, with older BIOSes, you couldn't even get it from ACPI unless you hooked the GPE directly because the required ACPI L/E methods were missing and were added by later versions of the T4x/R4x/X3x BIOS.
The EC firmware in a thinkpad is often more capable than what the BIOS exposes.
KEY_MUTE comes from the i8042 in Lenovo Thinkpads, only. And they started doing that when they removed the hardware volume control chip. It was retrofitted in later versions of the T60 BIOS (v2.x), I don't know how well though.
On Lenovo ThinkPads, it depends on BIOS/EC version for the X60/T60. Later versions will behave like the X61/T61. Since family 200 you can tell the EC to switch modes (latch, toggle, none), but Lenovo didn't test it well enough.
"none" seems to work well on all ThinkPads that I've tried. The other modes seem to have spotty support.
I am fine that we go with "none" and emulate everything in the driver where supported, yes.
This behavior is unfortunate, since modern userspace will also handle the hotkeys and change the other mixer. If the software
Like I said, we disable that by default, and userspace enables them back because they want to use it as a keyboard. We could override it entirely on the IBM thinkpads, and refuse to issue any key events no matter what, I suppose.
How? The only way I ever found to do that was using the i8042_filter in the older incarnations of this driver, and that was incredibly
You didn't try it on a IBM thinkpad, just on Lenovo thinkpads, then...
This should also allow us to remove _OSI(Linux) for all ThinkPads.
No, it doesn't. Only after an exaustive search for what _OSI(Linux) changes across a brickload of thinkpad ACPI dumps could we say that for sure.
I think we only need that for the four models in question. Also, all the commit messages for those quirk additions seem to suggest that they were done to improve volume controls. And I'm pretty sure I already checked at least one of those models (that's how I discovered HAUM/SAUM in the first place).
Anyway, patch 2 is optional.
Since you did due diligency, I'm fine with that. It is already in a separate patch, so it is easy to bissect and revert anyway.
- The EC or perhaps SMM firmware can optionally automatically change
- the volume in response to user input. Unfortunately, this rarely
It is the EC, which also emulates the i8042 KBC.
I don't see any problems with the code, will have to test it in a IBM thinkpad, though (I have one).
Please test v2 instead. :)
I will only be able to do that during the weekend anyway, so feel free to send a v3 if you need :-)
Any update?
--Andy
-- "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
On Sat, 25 Oct 2014, Andy Lutomirski wrote:
I will only be able to do that during the weekend anyway, so feel free to send a v3 if you need :-)
Any update?
Will test tomorrow, or with some luck, tonight... Had some nasty issues to deal with.
AFAICT the only reason to set _OSI(Linux) on ThinkPads is to get sensible mute button behavior. Now that the thinkpad_acpi driver can do this on is own, there is no reason to keep the ACPI quirk.
Cc: Len Brown len.brown@intel.com Cc: Jerone Young jerone.young@canonical.com Signed-off-by: Andy Lutomirski luto@amacapital.net --- drivers/acpi/blacklist.c | 54 ------------------------------------------------ 1 file changed, 54 deletions(-)
diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c index 36eb42e3b0bb..4a3cbb5d3c55 100644 --- a/drivers/acpi/blacklist.c +++ b/drivers/acpi/blacklist.c @@ -265,60 +265,6 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = { */
/* - * Lenovo has a mix of systems OSI(Linux) situations - * and thus we can not wildcard the vendor. - * - * _OSI(Linux) helps sound - * DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad R61"), - * DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T61"), - * T400, T500 - * _OSI(Linux) has Linux specific hooks - * DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X61"), - * _OSI(Linux) is a NOP: - * DMI_MATCH(DMI_PRODUCT_VERSION, "3000 N100"), - * DMI_MATCH(DMI_PRODUCT_VERSION, "LENOVO3000 V100"), - */ - { - .callback = dmi_enable_osi_linux, - .ident = "Lenovo ThinkPad R61", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), - DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad R61"), - }, - }, - { - .callback = dmi_enable_osi_linux, - .ident = "Lenovo ThinkPad T61", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), - DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T61"), - }, - }, - { - .callback = dmi_enable_osi_linux, - .ident = "Lenovo ThinkPad X61", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), - DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X61"), - }, - }, - { - .callback = dmi_enable_osi_linux, - .ident = "Lenovo ThinkPad T400", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), - DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T400"), - }, - }, - { - .callback = dmi_enable_osi_linux, - .ident = "Lenovo ThinkPad T500", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), - DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T500"), - }, - }, - /* * Without this this EEEpc exports a non working WMI interface, with * this it exports a working "good old" eeepc_laptop interface, fixing * both brightness control, and rfkill not working.
participants (2)
-
Andy Lutomirski -
Henrique de Moraes Holschuh