Thanks for your detailed reply Henrique, clarity much appreciated. Some
comments inline.
(Btw, an aside: Your post didn't make to the PA list for some reason,
at least not yet. Maybe it's being held for moderation? Anyway if any
moderators are reading this, please push Henrique's post thru to the list
so we have a complete record of the thread, thx.)
Henrique de Moraes Holschuh <hmh at hmh.eng.br> [2015-04-25 12:11:59 -0300]:
> On Fri, Apr 24, 2015, at 22:39, Glenn Golden wrote:
> > 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?
>
> Speaking as the thinkpad-acpi driver maintainer: Keeping the
> ThinkPad MUTE LED states in sync is the kernel's job. This is the
> beginning and the end of it.
>
Yep, I don't think there's any argument on that, at least not from me. That
was also the original take from David and Hui in response to the first post
on this thread:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-March/023551.html
Based on their responses, this kernel ticket was filed:
https://bugzilla.kernel.org/show_bug.cgi?id=96171
If you're interested in the gory details, see the "Report" attachment there.
Imo, the discussion on the kernel bugtracker got off track in terms of
establishing what the problem is and what it isn't. Your message here has
clarified that. I'm glad to help if I can in getting to the bottom of the
problem (see further below.)
>
> It clearly is not working properly right now. Possibly the
> defect is restricted to some thinkpads: Lenovo changes firmware
> behaviour sometimes. They're good about leaving a knob you can set
> to get whatever behaviour you want/need. They're not always that
> good about _testing_ it, though. And we (kernel side) are not that
> good at either knowing the behaviour exists, or making use of it.
>
> Or it might be a simple driver bug that affects every thinkpad
> with a mute LED. I hope so, because that's much easier to fix.
>
>
> Those are the facts. It doesn't look like there is anything
> pulse-audio related in this issue: it is a matter for the kernel
> to fix. Either in the ALSA sublayer, if it is not being able to
> correctly signal thinkpad-acpi to change Mute LED state, or in
> thinkpad-acpi if it is not correctly relaying to the thinkpar
> firmware the desired mute LED 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).
>
> And it is not going to be made available (in some thinkpads,
> it cannot even be done: when you change the hardware mute gate
> state, the EC updates the LED state to match). This is why we
> will consider any mute led misbehavior to be a kernel issue,
> to be fixed in the kernel.
>
Actually, I'd like to debate -- this is probably not the right place -- that a
more flexible solution looking forward, if feasible, would be to keep the mute
key as softkey just as now in 3.19, but also expose userspace interfaces to
both the HW mute and the mute LED on machines on which it is possible to do so.
This "everything bagel" approach would give everyone (individual users as well
as desktop environment designers) the flexibility to handle muting (and express
mute state) in whatever way suits them.
Imo, a problem with the present state of affairs in 3.19 (assuming a working
mute LED that correctly follows Playback Master mute state) is that the LED
is one bit of information that has to express two bits of mute state: One for
headphones and one for speaker. In contrast, in 3.18, the LED had a simple,
immutable semantic because it was tied to the HW mute gate: If the LED
was lit, no sound could come out of the speaker, period. So in the common
situation where you want to avoid blaring the speaker when you unplug the
headphones, you just toggled the mute button till the LED was lit, and you knew
with certainty that the speaker would be muted when you pulled the headphones.
Now, in 3.19 (without software_mute=0 boot option to revert behavior to 3.18)
if the LED is lit [assuming it is synched], it means only that the particular
output port currently selected by pavucontrol is muted. Insert or unplug the
headphones and the mute LED state may change, or it may not, depending on what
the other port's mute state is. So, suppose you have headphones plugged in and
they are muted, hence the mute LED is on. But the speaker may or may not be
muted; the LED tells you nothing about the speaker mute state. Now, pull the
headphones, and you don't know what's going to happen: The LED may turn off
and the speaker may blare. Or maybe not. Confusing imo. I'm sure others
disagree and prefer it the new way, but my point is not to debate which is
the "better" behavior, but that if both the HW mute gate and mute LED could
be exposed in userspace, then everyone could obtain whatever mute behavior
and LED behavior they prefer (to the extent that their machine is capable of.)
Even on machines in which the mute LED is hard-tied to the HW mute gate (as
you mention above) they could at least decide for themselves whether or not
to live with that approach or go with the softkey-controls-mixer approach.
It would also avoid the need for the "software_mute" boot option, since every
possible control of both HW mute gate and LED would be userspace available.
Anyway, just my 2c, and entirely distinct from the issue at hand. Let's get
the LED working as intended first.
>
> > 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.
>
>
> I lack the hardware to develop-and-test a fix (I am long overdue
> for a replacement thinkpad, really. I only have a good T43, and a
> damaged R60), but I am open to help (and ACK kernel-side patches).
>
I'm on the other side of that (T-510 but no knowledge of driver) but certainly
willing to roll up the sleeves and dig in if it can be done with reasonably
contained overhead to get to the point where I can build and test an
instrumented kernel module with some putative patches or diagnostic code.
Let me know what is needed, or point me to a good place to get started and
I'll contribute what I can to the effort in tracking this down.
Btw -- totally off topic, just for reminiscences about your T43 -- what a
superb piece of harware. I have two of 'em, and imo, they're among the best
laptops ever made. Found one with a rare UXGA (1600x1200) screen a couple
years ago, and it's been my primary ever since. No comparison to anything
being made today, including the T-510 (Lenovo) which honestly is kinda junky.
If you ever need T43 parts, let me know, I have quite a collection by now.
