[pulseaudio-discuss] ThinkPad T-510 audio output mute LED non-workingness

[Glenn Golden]

Raymond Yau <superquad.vortex2 at gmail.com> [2015-04-20 11:10:32 +0800]:
> 
> Refer to
> 
> http://www.spinics.net/lists/ibm-acpi-devel/msg03404.html
> 

That post has been pointed out several times.  I read it before my initial
posting of this thread.  Certainly I may have missed something, but it seems
to me that it contains nothing of relevance to this issue, other than
confirming that the kernel is not doing what it's supposed to be doing with
the mute LED vis a vis the Master Playback mute control. (At least, it isn't
doing it on my T-510).

Excerpt from the above:

>
> Starting with 3.19, the default behavior is to ask the embedded
> controller to disable all the magic.  The kernel will keep the mute
>                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> LED in sync with the software control, the hardware switch is disabled
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> entirely, and the mute button is just a button.
> 

The underlined sentence is exactly what is not happening on my T-510, and
_that_ is the issue.  The kernel (hda driver I assume they mean, but not sure)
isn't keeping the mute LED in synch with the software (i.e.  mixer) Master
Playback mute state.  That's why this would seem to be a kernel/driver bug,
just as David H and Hui Wang mentioned in the initial responses to this thread.

Since there also seems to be no direct access to the LED from userspace --
see earlier messages here and comment #15 on the kernel bugtracker explaining
what has already been tried in that regard -- and the kernel/driver is not
automatically keeping it in synch with the mixer Playback Master, it stays off.

>
> This mean the function of mute key is disabled by default
> 

Yes, but that's well known, and has already been commented on several times.
In 3.19 the mute key is a soft key. If the user doesn't field the event, 
it does nothing, that's true.  But afaict, it is also entirely irrelevant to
the problem being reported.

>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=9a417ec0c9d1f7af5394333411fc4d98adb8761b
> 
> Speaker still follow pin sense of hp and dock hp of hda codec when auto
> mute mode is enabled
> 

So what? What relation does that have with the mute LED not following the
mixer's Master Playback mute state? I don't see any. If you do, please be
explicit about it.

> 
> You need to find out how to listen mute key event
>

You need to pay attention to what's already been posted. :)  I do sincerely
appreciate your responsiveness on this issue, you've taken a lot of your
time to look into it. But it seems like you're kind of running open loop.

Listening for the mute key event is simple to do, and it's already been
explained several times why this is not directly relevant to the issue 
being reported: Fielding the mute key event isn't, by itself, going to
magically have any effect on the mute LED state. One has to take some action
in response to the event.  What action can be taken to turn on the mute LED?
Issue an amixer/pactl/pacmd command to toggle the Master Playback mute state?
No, that won't do it, because the LED isn't following the mixer mute state
(see earlier posts in this thread).  Directly access the LED via some exposed
interface to it?  No sign that any such any such interface is available in
/proc/acpi or /sys/class/leds (see comment #15 in the kernel bugtracker).

As I mentioned on the kernel bugtracker, I'm going to take this up with the
thinkpad ACPI folks, see if they have any suggestions.