[PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[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.

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.


Signed-off-by: Jerone Young <jerone.young@canonical.com>

diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index 2815df6..cce6e1a 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -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"),
+		},
+	},
 	{}
 };
 

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Henrique de Moraes Holschuh]

On Fri, 23 Apr 2010, Jerone Young wrote:
> 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.

> 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.

-- 
  "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

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

On Fri, 2010-04-23 at 23:01 -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 23 Apr 2010, Jerone Young wrote:
> > 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.

> 
> > 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. 



> 
> 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.


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



> 

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

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

On Fri, 2010-04-23 at 21:14 -0500, Jerone Young wrote:
> On Fri, 2010-04-23 at 23:01 -0300, Henrique de Moraes Holschuh wrote:
> > On Fri, 23 Apr 2010, Jerone Young wrote:
> > > 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.
> 
> > 
> > > 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. 
> 
> 
> 
> > 
> > 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.
> 
> 
> 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
> 
> 
> 
> > 
> 

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Henrique de Moraes Holschuh]

On Fri, 23 Apr 2010, Jerone Young wrote:
> > 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...

> 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.

> 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).

-- 
  "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

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

On Sat, 2010-04-24 at 00:10 -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 23 Apr 2010, Jerone Young wrote:
> > > 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...

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/linux-acpi@vger.kernel.org/msg12070.html

> 
> > 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.
> 
> > 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).

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

> 

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Matthew Garrett]

On Fri, Apr 23, 2010 at 05:48:04PM -0500, Jerone Young wrote:
> 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.
 
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

On Sat, 2010-04-24 at 17:01 +0100, Matthew Garrett wrote:
> On Fri, Apr 23, 2010 at 05:48:04PM -0500, Jerone Young wrote:
> > 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
>  

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Matthew Garrett]

On Sat, Apr 24, 2010 at 03:49:38PM -0500, Jerone Young wrote:

> 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?

> 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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

On Sat, 2010-04-24 at 22:16 +0100, Matthew Garrett wrote:
> On Sat, Apr 24, 2010 at 03:49:38PM -0500, Jerone Young wrote:
> 
> > 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

> > 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.


> 

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

On Sat, 2010-04-24 at 22:16 +0100, Matthew Garrett wrote:
> On Sat, Apr 24, 2010 at 03:49:38PM -0500, Jerone Young wrote:
> 
> > 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?
> 
> > 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

> 

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Henrique de Moraes Holschuh]

On Sat, 24 Apr 2010, Jerone Young wrote:
> On Sat, 2010-04-24 at 22:16 +0100, Matthew Garrett wrote:
> > On Sat, Apr 24, 2010 at 03:49:38PM -0500, Jerone Young wrote:
> > 
> > > 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.

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.

> 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.

-- 
  "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

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

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



On Sat, 2010-04-24 at 23:28 -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 24 Apr 2010, Jerone Young wrote:
> > On Sat, 2010-04-24 at 22:16 +0100, Matthew Garrett wrote:
> > > On Sat, Apr 24, 2010 at 03:49:38PM -0500, Jerone Young wrote:
> > > 
> > > > 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.
> 
> 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.
> 
> > 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.
> 

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Matthew Garrett]

On Sun, Apr 25, 2010 at 01:28:11PM -0500, Jerone Young wrote:

> 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.
 
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

On Sun, 2010-04-25 at 19:44 +0100, Matthew Garrett wrote:
> On Sun, Apr 25, 2010 at 01:28:11PM -0500, Jerone Young wrote:
> 
> > 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.

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

>  

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Matthew Garrett]

On Sun, Apr 25, 2010 at 01:57:52PM -0500, Jerone Young wrote:
> On Sun, 2010-04-25 at 19:44 +0100, Matthew Garrett wrote:
> > 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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

Providing more data here.

On Sat, 2010-04-24 at 23:28 -0300, Henrique de Moraes Holschuh wrote: 
> On Sat, 24 Apr 2010, Jerone Young wrote:
> > On Sat, 2010-04-24 at 22:16 +0100, Matthew Garrett wrote:
> > > On Sat, Apr 24, 2010 at 03:49:38PM -0500, Jerone Young wrote:
> > > 
> > > > 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.
> 
> 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).


> 
> 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.



> 
> > 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.

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 
> 

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

On Sun, 2010-04-25 at 19:59 +0100, Matthew Garrett wrote:
> On Sun, Apr 25, 2010 at 01:57:52PM -0500, Jerone Young wrote:
> > On Sun, 2010-04-25 at 19:44 +0100, Matthew Garrett wrote:
> > > 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
 
> 

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Henrique de Moraes Holschuh]

On Sun, 25 Apr 2010, Jerone Young wrote:
> On Sun, 2010-04-25 at 19:44 +0100, Matthew Garrett wrote:
> > On Sun, Apr 25, 2010 at 01:28:11PM -0500, Jerone Young wrote:
> > > 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.
> 
> 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.

> 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.

-- 
  "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

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Henrique de Moraes Holschuh]

On Sun, 25 Apr 2010, Jerone Young wrote:
> 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.

> > 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...

> 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.

> 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.

-- 
  "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

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

On Mon, 2010-04-26 at 07:38 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 25 Apr 2010, Jerone Young wrote:
> > 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.

> > > 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.
> 

Hmmm .. not my X301, I have the latest bios/ec update also.


> 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.

> 
> 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.

> 
> > 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.

It looks like not .. see first paragraph.

> 
> > 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. 

> 

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Jerone Young]

On Mon, 2010-04-26 at 07:11 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 25 Apr 2010, Jerone Young wrote:
> > On Sun, 2010-04-25 at 19:44 +0100, Matthew Garrett wrote:
> > > On Sun, Apr 25, 2010 at 01:28:11PM -0500, Jerone Young wrote:
> > > > 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.
> > 
> > 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.

> 
> It is taking more than two years to fix the last such "shortcut" (brightness
> control keys misused as notifications) taken because of userspace
> shortcomings.
> 
> > 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


> 

Re: [PATCH] Fix mute key on older Thinkpads by OSI blacklisting them

[Andy Lutomirski]

Jerone Young wrote:
> On Sat, 2010-04-24 at 22:16 +0100, Matthew Garrett wrote:
>> On Sat, Apr 24, 2010 at 03:49:38PM -0500, Jerone Young wrote:
>>
>>> 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?
>>
>>> 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!!).

[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