Fix mute key on older Thinkpads by OSI blacklisting them
PATCH 1/1 Fix mute key on older Thinkpads by OSI blacklisting them
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.
drivers/acpi/blacklist.c +40 -0
@@ -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"), + }, + }, {} };
Quoted 4 lines · Jerone Young
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.
Lenovo is getting really cheap those days if they now kill a BIOS that isn't even two years old.
Quoted 4 lines
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.
Depends on how the key behaves. Does the EC change from mute always mutes (and vol up/down unmutes) mode to mute does nothing (and thus you can dumb it down into a toggle) depending on OSI(Linux) ?
Also, should I scrap any support for Lenovo mute-only hardware mixers? OSI(Linux) seems to break it badly (but I'd appreciate some extensive testing of this, if you can do it... regular users often can't get userspace to quiet down enough to test it without external influences and I get mixed reports). Bit 6 of EC register 0x30 should control speaker muting.
Signature · 4 lines
"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
Quoted 8 lines · Henrique de Moraes Holschuh
Quoted 4 lines · Jerone Young
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.
Lenovo is getting really cheap those days if they now kill a BIOS that isn't even two years old.
Well they just will not have any update that would change the behavior. But yeah the BIOS for these are done.
Quoted 9 lines
Quoted 5 lines
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.
Depends on how the key behaves. Does the EC change from mute always mutes (and vol up/down unmutes) mode to mute does nothing (and thus you can dumb it down into a toggle) depending on OSI(Linux) ?
Yeap. So by setting OSI=Linux, the EC basically just makes the mute button an OS key press. The OS then mutes from the driver or higher level. This way both speakers & headphone jack get muted.
Quoted 7 lines
Also, should I scrap any support for Lenovo mute-only hardware mixers? OSI(Linux) seems to break it badly (but I'd appreciate some extensive testing of this, if you can do it... regular users often can't get userspace to quiet down enough to test it without external influences and I get mixed reports). Bit 6 of EC register
0x30should control speaker muting.
I think scrapping the support would be a good idea. After discovering the hardware mute was only wired to the speakers, and not the headphone jack. It seems best to let userspace do it, and this at least it is what Lenovo is doing for the newer Thinkpads now. But I can also understand that by doing this you depend on userspace to quiet down.
Well the T410 has interesting behavior. It actually does both at the same time. It sends the OS the mute key press & does a hardware mute to the speakers. This can fall out of sync of course if a user mutes from the userspace applet. But is easily remedied once the user presses the up or down volume key.
Given some of the new behavior it's probably best to crap it. I did some testing though before on this on the acpi-devel mailing list with my X301. I want to send the OSI patch for that as well. But the X300 & the X301 have the nice hardware mute light that some people love. So I will just have to add the command line for my machine for a while.
Thanks,
Jerone
Quoted 1 line
Errr .. Below I meant an earlier email I did on the thinkpad-acpi mailing list a while back testing out the mute led support you had.
Thanks,
Jerone
Quoted 62 lines · Jerone Young
Quoted 8 lines · Henrique de Moraes Holschuh
Quoted 4 lines · Jerone Young
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.
Lenovo is getting really cheap those days if they now kill a BIOS that isn't even two years old.
Well they just will not have any update that would change the behavior. But yeah the BIOS for these are done.
Quoted 9 lines
Quoted 5 lines
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.
Depends on how the key behaves. Does the EC change from mute always mutes (and vol up/down unmutes) mode to mute does nothing (and thus you can dumb it down into a toggle) depending on OSI(Linux) ?
Yeap. So by setting OSI=Linux, the EC basically just makes the mute button an OS key press. The OS then mutes from the driver or higher level. This way both speakers & headphone jack get muted.
Quoted 7 lines
Also, should I scrap any support for Lenovo mute-only hardware mixers? OSI(Linux) seems to break it badly (but I'd appreciate some extensive testing of this, if you can do it... regular users often can't get userspace to quiet down enough to test it without external influences and I get mixed reports). Bit 6 of EC register
0x30should control speaker muting.I think scrapping the support would be a good idea. After discovering the hardware mute was only wired to the speakers, and not the headphone jack. It seems best to let userspace do it, and this at least it is what Lenovo is doing for the newer Thinkpads now. But I can also understand that by doing this you depend on userspace to quiet down.
Well the T410 has interesting behavior. It actually does both at the same time. It sends the OS the mute key press & does a hardware mute to the speakers. This can fall out of sync of course if a user mutes from the userspace applet. But is easily remedied once the user presses the up or down volume key.
Given some of the new behavior it's probably best to crap it. I did some testing though before on this on the acpi-devel mailing list with my X301. I want to send the OSI patch for that as well. But the X300 & the X301 have the nice hardware mute light that some people love. So I will just have to add the command line for my machine for a while.
Thanks,
JeroneQuoted 1 line
Quoted 7 lines · Jerone Young
Quoted 3 lines
Depends on how the key behaves. Does the EC change from mute always mutes (and vol up/down unmutes) mode to mute does nothing (and thus you can dumb it down into a toggle) depending on OSI(Linux) ?
Yeap. So by setting OSI=Linux, the EC basically just makes the mute button an OS key press. The OS then mutes from the driver or higher level. This way both speakers & headphone jack get muted.
Ok. Please tell me which bit of the EC the BIOS touches to change modes since you did look at its innards. That will let me detect the current mode from inside thinkpad-acpi...
Quoted 5 lines
Well the T410 has interesting behavior. It actually does both at the same time. It sends the OS the mute key press & does a hardware mute to the speakers. This can fall out of sync of course if a user mutes from the userspace applet. But is easily remedied once the user presses the up or down volume key.
Argh.
Quoted 5 lines
Given some of the new behavior it's probably best to crap it. I did some testing though before on this on the acpi-devel mailing list with my X301. I want to send the OSI patch for that as well. But the X300 & the X301 have the nice hardware mute light that some people love. So I will just have to add the command line for my machine for a while.
I'd rather find out exactly how to sync things. Chances are very high the hardware mute gate powers *off* the speaker drivers (as it does on all thinkpads with the extra hardware speaker/headphone volume control).
Signature · 4 lines
"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
Quoted 5 lines · Henrique de Moraes Holschuh
Quoted 4 lines · Jerone Young
Quoted 3 lines
Depends on how the key behaves. Does the EC change from mute always mutes (and vol up/down unmutes) mode to mute does nothing (and thus you can dumb it down into a toggle) depending on OSI(Linux) ?
Quoted 7 lines
Quoted 3 lines
Yeap. So by setting OSI=Linux, the EC basically just makes the mute button an OS key press. The OS then mutes from the driver or higher level. This way both speakers & headphone jack get muted.
Ok. Please tell me which bit of the EC the BIOS touches to change modes since you did look at its innards. That will let me detect the current mode from inside thinkpad-acpi...
Not sure, this is based on the DSDT from my x301.. but here are the instructions:
\_SB.PCI0.LPC.EC.SAUM (0x02)
Actually this is identical to the condition found in an X61 (which is already in blacklist.c):
http://www.mail-archive.com/[email protected]/msg12070.html
Quoted 15 lines
Quoted 6 lines
Well the T410 has interesting behavior. It actually does both at the same time. It sends the OS the mute key press & does a hardware mute to the speakers. This can fall out of sync of course if a user mutes from the userspace applet. But is easily remedied once the user presses the up or down volume key.
Argh.
Quoted 5 lines
Given some of the new behavior it's probably best to crap it. I did some testing though before on this on the acpi-devel mailing list with my X301. I want to send the OSI patch for that as well. But the X300 & the X301 have the nice hardware mute light that some people love. So I will just have to add the command line for my machine for a while.
Quoted 3 lines
I'd rather find out exactly how to sync things. Chances are very high the hardware mute gate powers *off* the speaker drivers (as it does on all thinkpads with the extra hardware speaker/headphone volume control).
I belive at least under Windows they use a daemon to keep things in sync. I think with a vanilla Windows install it has the same sync issue. You have to have a userspace daemon monitoring the two. *Going off vague memory .. so take it with little confidence till can get a chance to really verify.
Jerone
Quoted 1 line
Quoted 4 lines · Jerone Young
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.
The correct way to handle this, as noted before, is to figure out what Windows does and implement that.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 8 lines · Matthew Garrett
Quoted 4 lines · Jerone Young
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.
The correct way to handle this, as noted before, is to figure out what Windows does and implement that.
The issue is the way Windows does it is through a userspace daemon. By making it OSI=Linux (just as with the Thinkpads currently already in blacklist.c ..*61 line) the machines just send the OS a key press.
Since newer thinkpads as well as most other OEM machines take this model. It provides a much better user experience then what it is like today.
Basically with these machines today you press the mute button:
- the speakers mute
- you get no OSD from the OS .. as it has no idea anything has happened
- the headphone jack doesn't mute
Thanks,
Jerone
Quoted 1 line
Quoted 3 lines · Jerone Young
The issue is the way Windows does it is through a userspace daemon. By making it OSI=Linux (just as with the Thinkpads currently already in
blacklist.c..*61 line) the machines just send the OS a key press.
And how does that userspace daemon receive the event?
Quoted 3 lines
Since newer thinkpads as well as most other OEM machines take this model. It provides a much better user experience then what it is like today.
It's a model-specific quirk in generic code, so it's massively desirable to avoid this especially since it encourages other OEMs to do the same kind of thing.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 7 lines · Matthew Garrett
Quoted 3 lines · Jerone Young
The issue is the way Windows does it is through a userspace daemon. By making it OSI=Linux (just as with the Thinkpads currently already in
blacklist.c..*61 line) the machines just send the OS a key press.And how does that userspace daemon receive the event?
Well it's a daemon and a suite. Don't know if you have ever seen a Thinkpad with Windows? .. but has a lot of Think tools & such. Apart of these tools is an OSD as well.
What I gather (could be wrong). It waits for some bit to change in th EC indicating the mute has been changed. Then it alerts Windows that an the event happens and changes things at that Level (maybe by sending a mute key press??) .. but at the Windows userspace Level things get muted and unmuted properly. In turn muting both speakers & headphones.
Jerone
Quoted 7 lines
Quoted 3 lines
Since newer thinkpads as well as most other OEM machines take this model. It provides a much better user experience then what it is like today.
It's a model-specific quirk in generic code, so it's massively desirable to avoid this especially since it encourages other OEMs to do the same kind of thing.
As mentioned in the first email, Lenovo has stopped doing this with the newly release Thinkpads (ex. X201 & T410). By blacklisting these they act the same as newer Thinkpads.
Quoted 1 line
Quoted 7 lines · Jerone Young
Quoted 6 lines · Matthew Garrett
Quoted 3 lines · Jerone Young
The issue is the way Windows does it is through a userspace daemon. By making it OSI=Linux (just as with the Thinkpads currently already in
blacklist.c..*61 line) the machines just send the OS a key press.
Quoted 5 lines
Quoted 1 line
And how does that userspace daemon receive the event?
Well it's a daemon and a suite. Don't know if you have ever seen a Thinkpad with Windows? .. but has a lot of Think tools & such. Apart of these tools is an OSD as well.
Matthew is quite used to ThinkPads, and so am I. Believe me, it should be an ACPI event, either HKEY or GPE. They don't do direct EC access in Windows if they can help it, least of all polled access...
Comparing GPEs across several IBM-heritage DSDTs (ignore the X100e and other OEM crap with a thinkpad name), I think it comes in as 'hotkeys' (i.e. 0x10xx HKEY events). Please enable the high eight bits on the thinkpad-acpi hotkey mask, assign keycodes to those keys, and tell me what you find. Make sure to have OSI(Linux) *disabled*, I very much doubt it works in "Linux" mode.
Quoted 2 lines
event happens and changes things at that Level (maybe by sending a mute key press??) .. but at the Windows userspace Level things get muted and
Most likely it will mute the mixer directly. And so should we, trying to sync states over the input layer using EV_KEY is UTTERLY BROKEN, and fully into Don't Ever Do That territory.
I will provide proper support through thinkpad-acpi (which is *NOT* a EV_KEY. EV_SW, a thinkpad-specific event, a poll()'able sysfs attribute...), if there is a need.
Signature · 4 lines
"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
I'll provide more data here.
I think it's not really possible to get it correct with thinkpad-acpi . The reason is the userspace sound server. In our case it's pulse audio. So we are no longer just dealing with ALSA anymore. So if the OS gets a proper hotkey event it is able to mute at the pulse audio level then, pulse audio does work at the ALSA level (toggling the mixer). thinkpad-acpi has no way to check on the status of pulse audio.
Under Windows Vista and above the userspace daemon is basically keeping the higher level userspace sound server in sync with what is going on at the hardware level. Microsoft moved to a userspace sound server with Windows Vista.
Thanks,
Jerone
Quoted 36 lines · Henrique de Moraes Holschuh
Quoted 7 lines · Jerone Young
Quoted 6 lines · Matthew Garrett
Quoted 3 lines · Jerone Young
The issue is the way Windows does it is through a userspace daemon. By making it OSI=Linux (just as with the Thinkpads currently already in
blacklist.c..*61 line) the machines just send the OS a key press.Quoted 5 lines
Quoted 1 line
And how does that userspace daemon receive the event?
Well it's a daemon and a suite. Don't know if you have ever seen a Thinkpad with Windows? .. but has a lot of Think tools & such. Apart of these tools is an OSD as well.
Matthew is quite used to ThinkPads, and so am I. Believe me, it should be an ACPI event, either HKEY or GPE. They don't do direct EC access in Windows if they can help it, least of all polled access...
Comparing GPEs across several IBM-heritage DSDTs (ignore the X100e and other OEM crap with a thinkpad name), I think it comes in as 'hotkeys' (i.e. 0x10xx HKEY events). Please enable the high eight bits on the thinkpad-acpi hotkey mask, assign keycodes to those keys, and tell me what you find. Make sure to have OSI(Linux) *disabled*, I very much doubt it works in "Linux" mode.
Quoted 2 lines
event happens and changes things at that Level (maybe by sending a mute key press??) .. but at the Windows userspace Level things get muted and
Most likely it will mute the mixer directly. And so should we, trying to sync states over the input layer using
EV_KEYis UTTERLY BROKEN, and fully into Don't Ever Do That territory.I will provide proper support through thinkpad-acpi (which is *NOT* a
EV_KEY.EV_SW, a thinkpad-specific event, a poll()'able sysfs attribute...), if there is a need.
Quoted 6 lines · Jerone Young
I think it's not really possible to get it correct with thinkpad-acpi . The reason is the userspace sound server. In our case it's pulse audio. So we are no longer just dealing with ALSA anymore. So if the OS gets a proper hotkey event it is able to mute at the pulse audio level then, pulse audio does work at the ALSA level (toggling the mixer). thinkpad-acpi has no way to check on the status of pulse audio.
This really isn't a problem. We have a mixer device for the Thinkpad's own mixer, and we can send ALSA events to indicate that its state has changed.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 9 lines · Matthew Garrett
Quoted 6 lines · Jerone Young
I think it's not really possible to get it correct with thinkpad-acpi . The reason is the userspace sound server. In our case it's pulse audio. So we are no longer just dealing with ALSA anymore. So if the OS gets a proper hotkey event it is able to mute at the pulse audio level then, pulse audio does work at the ALSA level (toggling the mixer). thinkpad-acpi has no way to check on the status of pulse audio.
Quoted 3 lines
This really isn't a problem. We have a mixer device for the Thinkpad's own mixer, and we can send ALSA events to indicate that its state has changed.
I think it is. Since pulse audio only pay attention to the Master mixer of the primary card. The Thinkpad EC shows up basically as a second audio card.
But again new Thinkpads don't need this. Since they send a soft keypress by default. So userspace catches it and changes the Master mixer to mute.
I think all this work isn't going to help the situation any. There appears to be a easy solution. Just a matter of getting the LEDs on some to light correctly, and see when the hardware mute is enabled.
Thanks,
Jerone
Quoted 1 line
Quoted 8 lines · Jerone Young
Quoted 3 lines · Matthew Garrett
This really isn't a problem. We have a mixer device for the Thinkpad's own mixer, and we can send ALSA events to indicate that its state has changed.
I think it is. Since pulse audio only pay attention to the Master mixer of the primary card. The Thinkpad EC shows up basically as a second audio card.
Good thing we have the source code to pulse, then.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 11 lines · Matthew Garrett
Quoted 8 lines · Jerone Young
Quoted 3 lines · Matthew Garrett
This really isn't a problem. We have a mixer device for the Thinkpad's own mixer, and we can send ALSA events to indicate that its state has changed.
I think it is. Since pulse audio only pay attention to the Master mixer of the primary card. The Thinkpad EC shows up basically as a second audio card.
Good thing we have the source code to pulse, then.
hehe ... yes thinking about it you can come up with some scheme to have pulse audio sync the master & the Thinkpad EC mixers. Though would get tricky.
Also the EC mixer doesn't seem to be working on my X301 currently...though not running the latest tip thinkpad-acpi.
But I think the issue now is for these older Thinkpads the mute does not send an event (without OSI(Linux)) .. meaning
1) something would have to poll the EC to see if the hardware mute is
enabled for the speakers
2) Then send a softkey event to the OS so the sound server (pulse
audio) can learn about it ..
3) Pulse will mute the Alsa Mixer, so the headphone jack will then mute
as well..
4) Then the users gets the nice on screen notification.
Or if you specify OSI(Linux) .. you basically just skip step one and go to step 2 on. Also (not trying to beat a dead horse) this is what the X201 is doing right now.
Jerone
Thanks,
Jerone
Quoted 1 line
Quoted 9 lines · Jerone Young
Quoted 8 lines · Matthew Garrett
Quoted 6 lines · Jerone Young
I think it's not really possible to get it correct with thinkpad-acpi . The reason is the userspace sound server. In our case it's pulse audio. So we are no longer just dealing with ALSA anymore. So if the OS gets a proper hotkey event it is able to mute at the pulse audio level then, pulse audio does work at the ALSA level (toggling the mixer). thinkpad-acpi has no way to check on the status of pulse audio.
Quoted 7 lines
Quoted 3 lines
This really isn't a problem. We have a mixer device for the Thinkpad's own mixer, and we can send ALSA events to indicate that its state has changed.
I think it is. Since pulse audio only pay attention to the Master mixer of the primary card. The Thinkpad EC shows up basically as a second audio card.
Fix userspace, don't break the kernel.
It is taking more than two years to fix the last such "shortcut" (brightness control keys misused as notifications) taken because of userspace shortcomings.
Quoted 3 lines
I think all this work isn't going to help the situation any. There appears to be a easy solution. Just a matter of getting the LEDs on some to light correctly, and see when the hardware mute is enabled.
It is a matter of keeping the hardware state and software states in sync.
Looking at it in any other way will result in gross, fragile hacks.
Signature · 4 lines
"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
Quoted 14 lines · Henrique de Moraes Holschuh
Quoted 13 lines · Jerone Young
Quoted 11 lines · Matthew Garrett
Quoted 6 lines · Jerone Young
I think it's not really possible to get it correct with thinkpad-acpi . The reason is the userspace sound server. In our case it's pulse audio. So we are no longer just dealing with ALSA anymore. So if the OS gets a proper hotkey event it is able to mute at the pulse audio level then, pulse audio does work at the ALSA level (toggling the mixer). thinkpad-acpi has no way to check on the status of pulse audio.
This really isn't a problem. We have a mixer device for the Thinkpad's own mixer, and we can send ALSA events to indicate that its state has changed.
Quoted 5 lines
Quoted 3 lines
I think it is. Since pulse audio only pay attention to the Master mixer of the primary card. The Thinkpad EC shows up basically as a second audio card.
Fix userspace, don't break the kernel.
I think going this route actually is more hacky .. by having a second sound device for this. My thoughts is all of this should be removed. Instead have somewhere where hardware mute state can be checked easily.
Quoted 5 lines
It is taking more than two years to fix the last such "shortcut" (brightness control keys misused as notifications) taken because of userspace shortcomings.
Quoted 7 lines
Quoted 3 lines
I think all this work isn't going to help the situation any. There appears to be a easy solution. Just a matter of getting the LEDs on some to light correctly, and see when the hardware mute is enabled.
It is a matter of keeping the hardware state and software states in sync.
Looking at it in any other way will result in gross, fragile hacks.
I agree. I think though that by trying to solve the whole problem at the thinkpad-acpi level makes it more hacky.
Instead having thinkpad-acpi just exposing the LEDs & hardware mute state. Then allowing a userspace daemon to see & manipulate these states is a more elegant solution. This way it can also query & manipulate higher level things, like sound servers (pulse audio) , and keep everyone in sync.
Thanks,
Jerone
Quoted 1 line
Providing more data here.
Quoted 10 lines · Henrique de Moraes Holschuh
Quoted 9 lines · Jerone Young
Quoted 7 lines · Matthew Garrett
Quoted 3 lines · Jerone Young
The issue is the way Windows does it is through a userspace daemon. By making it OSI=Linux (just as with the Thinkpads currently already in
blacklist.c..*61 line) the machines just send the OS a key press.And how does that userspace daemon receive the event?
Quoted 7 lines
Quoted 3 lines
Well it's a daemon and a suite. Don't know if you have ever seen a Thinkpad with Windows? .. but has a lot of Think tools & such. Apart of these tools is an OSD as well.
Matthew is quite used to ThinkPads, and so am I. Believe me, it should be an ACPI event, either HKEY or GPE. They don't do direct EC access in Windows if they can help it, least of all polled access...
No ACPI event is sent by the mute key. This is on my X301 & T61 (already in blacklist.c). They must be doing some polling, as I remember there being a slight delay when you press the mute key and Windows getting the update from the userspace daemon.
I've also described this in the past. For any machine past the *61 line of Thinkpads when Lenovo took over, the up down volume keys send soft kepresses. But the mute key does not send an event to the OS. Well unless OSI(Linux).
Quoted 7 lines
Comparing GPEs across several IBM-heritage DSDTs (ignore the X100e and other OEM crap with a thinkpad name), I think it comes in as 'hotkeys' (i.e. 0x10xx HKEY events). Please enable the high eight bits on the thinkpad-acpi hotkey mask, assign keycodes to those keys, and tell me what you find. Make sure to have OSI(Linux) *disabled*, I very much doubt it works in "Linux" mode.
Since it sends no acpi event there is no way for it to catch it. Could I be wrong?
I have do not have OSI(Linux) on. Also I see the other keys like lock & battery sending acpi events for thinkpad-acpi to catch. But the for the sound keys. Volume up & down send soft key presses. Mute sends nothing at all.
Quoted 11 lines
Quoted 3 lines
event happens and changes things at that Level (maybe by sending a mute key press??) .. but at the Windows userspace Level things get muted and
Most likely it will mute the mixer directly. And so should we, trying to sync states over the input layer using
EV_KEYis UTTERLY BROKEN, and fully into Don't Ever Do That territory.I will provide proper support through thinkpad-acpi (which is *NOT* a
EV_KEY.EV_SW, a thinkpad-specific event, a poll()'able sysfs attribute...), if there is a need.
The problem here as I describe in my last email is that thinkpad-acpi cannot full fix this issue. You need to have a userspace daemon to interact with the userspace sound server.
By using OSI(Linux) for these in particular. While they do not get hardware mute to the speakers, it provides a superior user experience with the big Linux Based Desktops OS of today. Also the big thing for users is the headphones don't mute. Also this is what new Thinkpads are doing out of the box.
What is getting me guys is that we have machines already doing this right now in the code from the same time period (They where put there to solve the exact same issue). This is just an extension of those machines. I think what we are discussing now is a separate possible solution. But for the short term we should black list these machines also, till can sort it out. Once it is we can unblack list all of them.
But most users just think something is wrong with Linux.
Thanks,
Jerone
Quoted 1 line
Quoted 4 lines · Jerone Young
No ACPI event is sent by the mute key. This is on my X301 & T61 (already in
blacklist.c). They must be doing some polling, as I remember there being a slight delay when you press the mute key and Windows getting the update from the userspace daemon.
Please test on the T400 and T410, if possible.
Quoted 9 lines
Quoted 6 lines
Comparing GPEs across several IBM-heritage DSDTs (ignore the X100e and other OEM crap with a thinkpad name), I think it comes in as 'hotkeys' (i.e. 0x10xx HKEY events). Please enable the high eight bits on the thinkpad-acpi hotkey mask, assign keycodes to those keys, and tell me what you find. Make sure to have OSI(Linux) *disabled*, I very much doubt it works in "Linux" mode.
Since it sends no acpi event there is no way for it to catch it. Could I be wrong?
There are three new HKEY events on some of the newer thinkpads (I don't know if they exist in the X300/X301). They're hooked to suspicious GPEs that are the same as the ones for volume feedback on all other thinkpads.
Whatever solution I will adopt, won't be one for the X300 in particular. It needs to be one that won't be a hindrance in the next two years at least.
I need more data on the newest models first, to make an informed decision. It is entirely possible that the X300/T61 generation require a different solution than the earlier models. And it is entirely possible that the T410 and newer allow for a better solution than the X300/T61.
EC polling is bad, hardware state unsynced is worse. And any polling done in userspace is Ugly, Bad, and will bite us back when it is not needed anymore.
thinkpad-acpi is perfectly capable of doing polling on its own so that it becomes transparent to userspace, and userspace won't screw over the owners of thinkpads that don't need polling.
So, it is not that I am against the OSI(Linux) patch. But I *do* want the full data...
Quoted 3 lines
The problem here as I describe in my last email is that thinkpad-acpi cannot full fix this issue. You need to have a userspace daemon to interact with the userspace sound server.
But you can send full state messages using EV_SW or some other channel, to force userspace into sync with the hardware state (if we can get to the hardware state). I'd rather find out whether we need that on the newest generation of thinkpads *before* userspace starts expecting a certain behaviour from the thinkpad.
Quoted 6 lines
What is getting me guys is that we have machines already doing this right now in the code from the same time period (They where put there to solve the exact same issue). This is just an extension of those machines. I think what we are discussing now is a separate possible solution. But for the short term we should black list these machines also, till can sort it out. Once it is we can unblack list all of them.
I don't mind short-term solutions. But I *do* mind any future pressure to keep them around instead of fixing things properly even if we will need to break userspace hacks. I am not yet sure this won't be the case, here.
Signature · 4 lines
"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
Quoted 7 lines · Henrique de Moraes Holschuh
Quoted 4 lines · Jerone Young
No ACPI event is sent by the mute key. This is on my X301 & T61 (already in
blacklist.c). They must be doing some polling, as I remember there being a slight delay when you press the mute key and Windows getting the update from the userspace daemon.Please test on the T400 and T410, if possible.
The T410 sends a soft keypress & hardware keypress at the same time (it also turns on the LED on the mute key .. which indicates the hardware mute is on for the speakers). No acpi event.
With the X201 & W510 (2nd hand data on the W510) they ONLY send a mute soft keypress .. no more hardware mute. So no way to fall out of sync. They also don't have a LED on the mute key. No acpi event.
Unfortunately don't have or know anyone around with a T400 to get more data from it. But looks like any machine Lenovo produced during this time had the exact same thing going on.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Comparing GPEs across several IBM-heritage DSDTs (ignore the X100e and other OEM crap with a thinkpad name), I think it comes in as 'hotkeys' (i.e. 0x10xx HKEY events). Please enable the high eight bits on the thinkpad-acpi hotkey mask, assign keycodes to those keys, and tell me what you find. Make sure to have OSI(Linux) *disabled*, I very much doubt it works in "Linux" mode.
Quoted 7 lines
Quoted 2 lines
Since it sends no acpi event there is no way for it to catch it. Could I be wrong?
There are three new HKEY events on some of the newer thinkpads (I don't know if they exist in the X300/X301). They're hooked to suspicious GPEs that are the same as the ones for volume feedback on all other thinkpads.
Hmmm .. not my X301, I have the latest bios/ec update also.
Quoted 7 lines
Whatever solution I will adopt, won't be one for the X300 in particular. It needs to be one that won't be a hindrance in the next two years at least.
I need more data on the newest models first, to make an informed decision. It is entirely possible that the X300/T61 generation require a different solution than the earlier models. And it is entirely possible that the T410 and newer allow for a better solution than the X300/T61.
Looks like on the newest Models. Lenovo is beginning to move away from hardware mute.
Quoted 11 lines
EC polling is bad, hardware state unsynced is worse. And any polling done in userspace is Ugly, Bad, and will bite us back when it is not needed anymore.
thinkpad-acpi is perfectly capable of doing polling on its own so that it becomes transparent to userspace, and userspace won't screw over the owners of thinkpads that don't need polling.
So, it is not that I am against the OSI(Linux) patch. But I *do* want the full data...
Sure that sounds reasonable.
Quoted 10 lines
Quoted 4 lines
The problem here as I describe in my last email is that thinkpad-acpi cannot full fix this issue. You need to have a userspace daemon to interact with the userspace sound server.
But you can send full state messages using
EV_SWor some other channel, to force userspace into sync with the hardware state (if we can get to the hardware state). I'd rather find out whether we need that on the newest generation of thinkpads *before* userspace starts expecting a certain behaviour from the thinkpad.
It looks like not .. see first paragraph.
Quoted 11 lines
Quoted 7 lines
What is getting me guys is that we have machines already doing this right now in the code from the same time period (They where put there to solve the exact same issue). This is just an extension of those machines. I think what we are discussing now is a separate possible solution. But for the short term we should black list these machines also, till can sort it out. Once it is we can unblack list all of them.
I don't mind short-term solutions. But I *do* mind any future pressure to keep them around instead of fixing things properly even if we will need to break userspace hacks. I am not yet sure this won't be the case, here.
I could agree. Though after seeing the behavior of the new Thinkpads I realized Lenovo was just making the bahavior exactly what they had OSI(Linux) on the old Thinkpads.
Quoted 1 line
Quoted 8 lines · Matthew Garrett
Quoted 3 lines · Jerone Young
The issue is the way Windows does it is through a userspace daemon. By making it OSI=Linux (just as with the Thinkpads currently already in
blacklist.c..*61 line) the machines just send the OS a key press.And how does that userspace daemon receive the event?
Quoted 7 lines
Quoted 3 lines
Since newer thinkpads as well as most other OEM machines take this model. It provides a much better user experience then what it is like today.
It's a model-specific quirk in generic code, so it's massively desirable to avoid this especially since it encourages other OEMs to do the same kind of thing.
Also to mention Matt that this is already done in the code for the *61 line, T400, T500, R400. All of these are from the same production time period. Please see drivers/acpi/blacklist.c.
These machines will not change and are not getting BIOS updates to change. They have finished there production run.
It may be just me. But I'm failing to see why this is a big deal. If the others where put in to fix them, newer Thinkpad models have stopped this behavior, and these Thinkpads will not be getting updated. Users with these models are going to have a bad experience when it comes to muting.
I personally use an X301. I would put that in as well, but there is a little light on it.. that none of the models in the patch have. That lets you know the hardware mute is on, I've seen some people really like that (had a proposed patch in last Ubuntu release and got bugs saying...What happened to my mute light!!).
Thanks,
Jerone
Quoted 1 line
Quoted 26 lines · Jerone Young
Quoted 11 lines · Matthew Garrett
Quoted 3 lines · Jerone Young
The issue is the way Windows does it is through a userspace daemon. By making it OSI=Linux (just as with the Thinkpads currently already in
blacklist.c..*61 line) the machines just send the OS a key press.And how does that userspace daemon receive the event?
Quoted 3 lines
Since newer thinkpads as well as most other OEM machines take this model. It provides a much better user experience then what it is like today.
It's a model-specific quirk in generic code, so it's massively desirable to avoid this especially since it encourages other OEMs to do the same kind of thing.
Also to mention Matt that this is already done in the code for the *61 line, T400, T500, R400. All of these are from the same production time period. Please see
drivers/acpi/blacklist.c.These machines will not change and are not getting BIOS updates to change. They have finished there production run.
It may be just me. But I'm failing to see why this is a big deal. If the others where put in to fix them, newer Thinkpad models have stopped this behavior, and these Thinkpads will not be getting updated. Users with these models are going to have a bad experience when it comes to muting.
Quoted 5 lines
I personally use an X301. I would put that in as well, but there is a little light on it.. that none of the models in the patch have. That lets you know the hardware mute is on, I've seen some people really like that (had a proposed patch in last Ubuntu release and got bugs saying...What happened to my mute light!!).
[warning: I don't understand ALSA *at all*.] How hard would it be for the kernel to report the extra Thinkpad mixer as *part* of the main sound card? Something though a platform driver and a hook in hda_intel or its codecs, maybe? The X301 mute light could work the same way (have the sound driver notify the ACPI driver that the master mixer is muted and then turn on the light, or use a tiny userspace daemon to do exactly the same thing).
It seems rather overcomplicated to implement either a second mixer or some special-purpose thinkpad_acpi driver and then hack userspace to understand that the kernel is unable to report sanely what the hardware actually does.
OTOH, OSI(Linux) already makes the hardware work sensibly, and the user experience on Windows is ugly enough that I don't see any good reason to emulate it.
--Andy