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.
