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

[Jerone Young <jerone.young@canonical.com>]

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


>