David Henningsson <david.henningsson at canonical.com> [2015-04-15 07:14:59 +0200]:
>
>
> On 2015-03-30 23:54, Glenn Golden wrote:
> >HW: ThinkPad T-510, x86_64
> >SW: Arch Linux (synched within a week) kernel = 3.19.2, PA 6.0
>
> I think I found the offending commit [1]:
>
> commit 9a417ec0c9d1f7af5394333411fc4d98adb8761b
> Author: Andy Lutomirski <luto at MIT.EDU>
> Date: Fri Oct 17 17:04:29 2014 -0700
>
> thinkpad-acpi: Try to use full software mute control
>
> It was added between 3.18 and 3.19 and concerns mute keys on Thinkpads.
>
TTBOMU, this commit is not the source of the problem, although it is
indirectly related to it. I was aware of this 3.18 -> 3.19 key handling
change when I filed the original post here. Raymond also called this out
earlier in the thread here.
Please see the "background" section of the detailed report referred to
in Comment #3 here
https://bugzilla.kernel.org/show_bug.cgi?id=96171
It explains in detail the relationship between that commit and the LED issue,
and explains exactly what the bug is and what the bug isn't. The bug _isn't_
that the mute key handling was changed from driver fielded to user-fielded.
That was intentional and not a bug in an of itself.
The bug -- or more correctly, one of the two sub-bugs -- _is_ that the
hardware-based speaker-only mute _action_ that was being taken by the driver
in 3.18 (in response to an AudioMute keypress) is distinct from the
pavucontrol/pactl mixer-based mute action. And it is that "other" action
(the hardware speaker-only mute action) that (in 3.18) was also associated
with the LED toggling. That hardware action (and associated LED toggling)
is evidently not available via pavucontrol/pactl mute (and was even not
available via pavucontrol/pactl mute even in 3.18)
> >Knowing the answer to this, I can post a more informative ticket to the
> >kernel guys. (Or maybe the fix is even in pulseaudio itself?)
>
> Maybe you could also try one of the thinkpad-acpi mailinglists [2].
>
I looked at the TP ACPI Wiki and some of the posts on the list before posting
this thread. Nothing I saw there seemed to cover the specific situation
regarding the AudioMute LED. The stuff that I came across there just discusses
the need to add events handlers for the AudioMute and MicMute buttons,
since they're no longer handled by the driver, starting with 3.19. This was
was well known to me.
Again, the report has all the gory details.
