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

[Glenn Golden]

Henrique de Moraes Holschuh <hmh at hmh.eng.br> [2015-05-04 10:16:21 -0300]:
> 
> Well, your firmware does not have SSMS, at all.  It is not that thinkpad-acpi
> can't find it due to some change in the acpi core, it simply isn't there to
> be found.
> 

OK, thanks for the detective work, Henrique.

In the interest of documenting what's been learned here (at least by me),
what follows is an attempt at a detailed summary/guide to ThinkPad mute key
and mute LED behavior when transitioning from 3.18 to 3.19 kernels. Perhaps
it may be useful to others who are also head-scratching about this issue,
since it involves quite a few moving parts.

It would be great if you could look it over when you have a chance, and
correct or bless it as you see fit. I'll also pass it by the PA folks and then
post the result to both the original PA ML thread and to the ThinkPad ACPI ML
as well (if you want).

Thanks again for your time and assistance on this. (H/T also to David,
Raymond, and Takashi).

Glenn

=============================================================================
For TP models like the T-510 (and others without the SSMS mute LED interface):

 0.  If you want your mute LED to do anything (other than be permanently off)
     you have no choice but to set acpi.software_mute=0 at boot time, which
     reverts to 3.18 behavior.  If you do this, then 1-3 below apply.  If you
     don't care whether your mute LED works, then 4-8 further below apply.

 1.  The embedded controller (EC) fields mute key events directly, and in
     response, toggles both the hardware speaker mute gate and the mute LED
     (if you have one). The kernel is not involved in these actions at all.

 2.  "Mute LED on" means, unequivocally, that the hardware mute gate is 
     clamped, i.e. no sound can emit from the speaker, period.  The hardware
     mute gate has no effect on headphone mute state.

 3.  If you happen to already have the mute key mapped via userspace event
     to do something with the mixer mute state (e.g. via amixer/pactl/pacmd,
     etc.) you should probably disable that mapping in order to avoid
     unintended conflicts and/or mild insanity.


For ThinkPad models having the SSMS interface, the behavior in 3.18 is just as
described in 1-3 above: The EC controls hardware speaker-mute gate and LED.
If you're happy with that behavior, then when transitioning to 3.19 just set
acpi.software_mute=0 at boot time, and you'll still have it.

Otoh, if you would like to have softkey control over mute action via mixer
mute (in contrast to the hardware speaker-mute in 3.18) then don't supply the
acpi.softkey=0 boot option, and the following apply:

 4.  Hardware speaker-mute is completely disabled: The EC does not field mute
     key events, nor does it touch the hardware mute gate control. The HW mute
     gate is permanently unclamped and inaccessible via kernel or userspace.

 5.  The mute key becomes a softkey, and muting must be performed via the
     mixer. The kernel autonomously takes care of synching the mute LED with
     the mixer "Playback Master" mute setting.

 6.  If you want your mute key to do anything, you have to set up an event
     handler to do whatever it is you want it to do.

 7.  If you elect to have the mute key toggle the Playback Master mute via an
     event which invokes pactl/pacmd/amixer/[insert fave mixer control tool]
     then the mute LED will automatically follow the Playback Mute state as
     mentioned above, thus no explicit action is required to make the LED work.
     But! ...

 8.  ...because [Alsa? Pulseaudio?] maintains two independent mixer mute state
     variables -- one for headphone port, one for speaker port -- the semantics
     of both the mute key and the mute LED become less straightforward than
     with the hardware-based mute in 3.18.  Specifically:

       * The mute key (via your userspace mixer control event handler) will
	 toggle whichever port (HPH or SPKR) happens to be active at that time,
	 and will have no effect on the mute state of the other port.

       * The mute LED will likewise follow the mute state of the active port
	 via kernel auto-synch (as described above).

     Taken together, these imply that no unequivocal semantic can be attached
     to "mute LED on", as it was with hardware-based mute: All you can say is
     that if the LED is on, then the active port is muted via the mixer;
     the LED gives no information about the inactive port's mute state.  One
     consequence of this is that the mute LED may (or may not) change state
     simply by the action of inserting or removing the headphone plug.  
=============================================================================