Bug 96171

http://support.lenovo.com/us/en/documents/pd025599


The built-in volume buttons enable you to quickly adjust the volume or mute the sound from your computer.



page 74 of ThinkPad T510, T510i,and W510 Hardware Maintenance Manual

Table7.Status indicators 

Indicator
Speaker mute 
Orange: The speaker is on mute.To set the speakers on mute or unmute,press the speaker mute button. 

Microphone mute 
Orange: The microphone is on mute.None of the recording devices is available while the microphone mute is on by default.





"mute the sound from your computer"

seem slightly different from 

"To set the speakers on mute or unmute,press the speaker mute button"


Do the speaker unmute when headpone is plugged when you press mute button ?

Do the headphone mute when you press the mute button ?

Do you mean the current implemenation using vmaster hook is incorrect ?

Raymond, thanks for your attention to this, much appreciated.

Since this is a regression issue between 3.18 and 3.19.2, rather than replying to your questions based on the current kernel I'm running (3.19.2) let me do some careful comparison experiments this coming weekend between the two, and I will then post a detailed summary of the results.

I want to avoid being too glib in my responses to your questions, because there are a lot of behaviors that differ subtly between the two kernels other than just the LED, including (as I think you're getting at with your questions) whether there are two independent mute states (one for speakers, one for headphone) or just one that pertains to both ports. My recollection is that 3.18 maintained just one state that pertained to both ports, but not positive of that. (For sure, 3.19.2 definitely maintains separate state for each port.)

Anyway, I'll post more here in a few days. 

Thanks again for your time on this.

Created attachment 174051 [details]
Report

Created attachment 174061 [details]
Behavioral schematic

Raymond,

Attached is a detailed report on the observed muting behavior of the T-510
under PulseAudio 6.0, comparing the behavior between kernel 3.18.6 vs. the
behavior with 3.19.2 or 3.19.3 (the latter two seem to behave identically).

I think this addresses the questions you asked, except the last one about the
vmaster hook: I have no knowledge of this at all.

If you want to skip the verbosity of the report and just get the big picture,
have a look at the attached "behavioral schematic" which seems to summarize the
situation.

Thanks again for your time on this. Let me know if you have any questions.

- Glenn

there are difference between

amixer -c 1 set Master toggle

and

pactl set-sink-mute toggle




do turn on/off of mute led depend on the state of the mono virtual master playback switch ?


Card hw:0 'MID'/'HDA Intel MID at 0xf2620000 irq 28'
  Mixer name	: 'Intel IbexPeak HDMI'
  Components	: 'HDA:14f15069,17aa218b,00100302 HDA:80862804,17aa21b5,00100000'
  Controls      : 47
  Simple ctrls  : 16
Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined
  Playback channels: Mono
  Limits: Playback 0 - 74
  Mono: Playback 74 [100%] [0.00dB] [on]

whether the speaker is muted by the driver depends on the jack state of both headphone jack controls

control.16 {
		iface CARD
		name 'Dock Headphone Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.17 {
		iface CARD
		name 'Headphone Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}

(In reply to G. Golden from comment #3)
> Created attachment 174051 [details]
> Report

jack 
NID 0x19: cfg 0x042110ff: [Jack] HP Out at Ext Right 
NID 0x1a: cfg 0x21a190f0: [Jack] Mic at Sep Rear 
NID 0x1b: cfg 0x04a110f0: [Jack] Mic at Ext Right 
NID 0x1c: cfg 0x212140ff: [Jack] HP Out at Sep Rear 
NID 0x1f: cfg 0x901701f0: [Fixed] Speaker at Int N/A 
.NID 0x23: cfg 0x90a601f0: [Fixed] Mic at Int N/A

jack 0x19 1 
send: NID=0x19, VERB=0xf09(get_pin_sense), PARM=0x0 
receive: 0x80000000 
send: NID=0x1f, VERB=0x707(set_pin_ctl), PARM=0x0 
receive: 0x0 
CTL Notify: Headphone Jack:0, mask=1 
JACK report Headphone, status 1 
JACK report Dock Headphone, status 0 
JACK report Dock Mic, status 0 
JACK report Mic, status 0

jack 0x19 0 
send: NID=0x19, VERB=0xf09(get_pin_sense), PARM=0x0 
receive: 0x0 
send: NID=0x1f, VERB=0x707(set_pin_ctl), PARM=0x40 
receive: 0x0 
CTL Notify: Headphone Jack:0, mask=1 
JACK report Headphone, status 0 
JACK report Dock Headphone, status 0 
JACK report Dock Mic, status 0 
JACK report Mic, status 0


the driver just set pin ctl of speaker to zero when headphone jack or dock headphone jack is plugged


get 11
11 Master Playback Switch:0 MIN/MAX: 0/1, VAL: [0] 

set 11 1 
send: NID=0x10, VERB=0x3a0(set_amp_gain_mute,O:L#0), PARM=0x0 
receive: 0x0 
send: NID=0x10, VERB=0x390(set_amp_gain_mute,O:R#0), PARM=0x0 
receive: 0x0 
send: NID=0x11, VERB=0x3a0(set_amp_gain_mute,O:L#0), PARM=0x0 
receive: 0x0 
send: NID=0x11, VERB=0x390(set_amp_gain_mute,O:R#0), PARM=0x0 
receive: 0x0 
Setting thinkpad LED 0 to off

set 11 0 
send: NID=0x10, VERB=0x3a0(set_amp_gain_mute,O:L#0), PARM=0x80 
receive: 0x0 
send: NID=0x10, VERB=0x390(set_amp_gain_mute,O:R#0), PARM=0x80 
receive: 0x0 send: NID=0x11, VERB=0x3a0(set_amp_gain_mute,O:L#0), PARM=0x80 
receive: 0x0 
send: NID=0x11, VERB=0x390(set_amp_gain_mute,O:R#0), PARM=0x80 
receive: 0x0 
Setting thinkpad LED 0 to on

it seem mute/unmute virtual master playback switch toggle thinkpad led on/off and mute/unmute amp ou in node 0x10 and node 0x11
the problem is the user application did not receive notification of change of speaker playback switch and headphone playback switch

bugzilla-daemon@bugzilla.kernel.org <bugzilla-daemon@bugzilla.kernel.org> [2015-04-15 01:30:52 +0000]:
> https://bugzilla.kernel.org/show_bug.cgi?id=96171
> 
> --- Comment #6 from Raymond <superquad.vortex2@gmail.com> ---
> there are difference between
> 
> amixer -c 1 set Master toggle
> 
> and
> 
> pactl set-sink-mute toggle
> 

Yes, I'm aware of the differences between them:

   amixer set Master toggle

toggles only the Master Playback mute, whereas

   pactl set-sink-mute toggle

toggles both the Master Playback mute _and_ the mute of the particular port
that is currently selected.

But neither of the above affects the mute LED. The LED is always off.
   
> 
> do turn on/off of mute led depend on the state of the mono virtual master
> playback switch ?
> 

No. The LED is always off, regardless of the state of the virtual master
playback switch. This topic was discussed yesterday here:

    http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-April/023638.html

bugzilla-daemon@bugzilla.kernel.org <bugzilla-daemon@bugzilla.kernel.org> [2015-04-15 04:16:10 +0000]:
> https://bugzilla.kernel.org/show_bug.cgi?id=96171
> 
> --- Comment #7 from Raymond <superquad.vortex2@gmail.com> ---
> whether the speaker is muted by the driver depends on the jack state of
> both headphone jack controls
> 

I think that the speaker silencing action based on jack state is not the
same as "muting".  I referred to this silencing action in the report as
"QUIET"ing, rather than muting, just for this reason, i.e. to avoid
confusion between the two reasons for speaker silencing.

The speaker QUIETing seems to be entirely normal in all respects: When 
headphones are not plugged in, audio is directed to the speaker and the
port indicator on pavucontrol says "Speaker". If headphones are then
plugged in, the port indicator on pavucontrol switches to "Headphones
(plugged in)", and audio is then directed to the headphones and not to
the speaker. But this is QUIETing, not muting.

In the report, "muting" refers to silencing of the speaker output even when 
the "Speaker" port is selected, i.e. when headphones are not plugged in.

bugzilla-daemon@bugzilla.kernel.org <bugzilla-daemon@bugzilla.kernel.org> [2015-04-15 07:41:14 +0000]:
> https://bugzilla.kernel.org/show_bug.cgi?id=96171
> 
> --- Comment #8 from Raymond <superquad.vortex2@gmail.com> ---
> 
> the driver just set pin ctl of speaker to zero when headphone jack or dock
> headphone jack is plugged
> 

Yes, that's QUIETing, and it's working just fine. There is no issue with
QUIETing at all.

Please read the report, it contains all this info. I'm just repeating myself
here.

> 
> it seem mute/unmute virtual master playback switch toggle thinkpad
> led on/off
>

No, it does not. Neither "amixer set Master toggle" nor "pactl set-sink-mute
toggle" affect the mute LED state.  Both of these commands DO toggle the
virtual Master Playback mute indicator ("MM/OO") and the actual audio itself;
but they do not affect the LED state at all, in either 3.18 or in 3.19.

>
> the problem is the user application did not receive notification of
> change of speaker playback switch and headphone playback switch
> 

Perhaps I'm misunderstanding what you mean here, but it seems to me that
this notification is not the problem:  Pavucontrol always correctly displays
the port that corresponds to the state of the headphone jack: If headphones
are NOT plugged in, then the pavucontrol "Port" indicator displays "Speaker".
If headphones are then plugged in, the pavucontrol "Port" indicator 
automatically switches to "Headphones (plugged in)".  And audio is always
directed to the proper port (i.e. audio -> headphones if headphones are
plugged in, and audio -> speakers if headphones are not plugged in.)

Based on this, it seems that PulseAudio must be properly detecting the
speaker/headphone notification events, otherwise its port indication would
not be automatically changing.

Am I missing your point?

ctl.!default {
    type pulse
    fallback "sysdefault"
}

#ctl.!default {
#  type hw
#  card 0
#}

amixer set Master toggle only toggle pulseaudio master playback switch


you have to specify -c 0 for your conexant codec's virtual master playback switch when you override ctl.default by pulse plugin

amixer -c0 set Master toggle


http://git.alsa-project.org/?p=alsa-plugins.git;a=blob;f=doc/README-pulse;hb=HEAD

When "fallback" option is set, the plugin will try to open the given PCM
   (or control) automatically when connecting to PA server fails.  Typically,
   it should point to "sysdefault", which was introduced recently in alsa-lib,
  so that the system-default setup is used even when you overwrite "default"
   PCM and control definitions.

I specified "-c 0" in the actual command that I experimented with. I didn't show the "-c 0" in my reply above only as shorthand to avoid confusion, since you had given your example with "-c 1", which doesn't apply to my setup. On my setup, card 0 is the proper one, and didn't want you to think I was experimenting with card 1.

The actual commands that I experimented with were, verbatim:


    amixer -c 0 set Master toggle


and

    pactl set-sink-mute 0 toggle


The results of these commands were verified by looking at the ALSAmixer GUI. The expected changes to the mute states occurred as I described in the earlier post.

Raymond, if it would be useful to you, I can post a small video (screen + audio) showing anything that you would like to see, in terms of my user actions, commands, GUI responses, the LED responses, and so on. Just let me know exactly what you want me to show, and I will do so.

I'm pretty sure though that you're barking up the wrong tree here. If you read the report in detail, I think you'll agree that there is very strong evidence that control of the mute LED is completely independent of and unrelated to the Playback Master mute state, despite David's understanding to the contrary. 

Even in 3.18, the mute LED was unaffected by ANY mute-related action taken via  pavucontrol, via pactl, via pacmd, or via amixer. The ONLY action that controlled the mute LED was pressing the mute key. The mute key in turn was being fielded by the driver; the driver in turn toggled some sort of _hardware_ mute switch that affected the speaker (and ONLY the speaker, not headphones) just as shown in the "behavioral" diagram. AND... it also toggled the mute LED. 

Every piece of evidence that I've seen so far, during many hours of playing around with this, suggests that the situation is accurately shown in the "behavioral diagram". This diagram is also consistent with the description of the 3.18 -> 3.19 change in reference [1] of the report, which says:

   The ThinkPad ACPI driver is now doing software muting rather than the 
   hardware-based muting of sound. ThinkPad laptops commonly have hardware
   volume controls going back years for muting and volume up/down. The muting
   is done at the hardware volume control....


So, I suspect that the notion that the Playback Master mute on the mixer should be affecting the mute LED is just mistaken, at least for this laptop.

To address this issue, what is needed is a way from userspace to toggle the very same hardware speaker-only mute switch that was being toggled by the driver in 3.18, as well as control of the mute LED. Having those two capabilities from userspace -- hardware speaker mute and LED control -- will entirely solve this problem and give users the ability to handle muting AND the state of the LED in whatever way suits them, via userspace control.

I am 99.9% sure that neither of those capabilities is accessible via pactl/pacmd/pavucontrol/amixer.

See attached script "mutescr". It does as described in the comments, i.e. hardware mute of the speakers and headphones, channel by channel. The parameter 0 was used in all cases, but changing the parameter to 0x80 gives identical results.

It has no effect on the mute LED; the LED remains off.

This would seem to confirm that the mute LED is not bound to the hardware mute function, but is separately controlled (which is as would be expected).

So I'm not sure why in your above post you said:

   Setting thinkpad LED 0 to on
   Setting thinkpad LED 0 to off

It doesn't happen via my script anyway. 

Just for completeness, some other things I had tried before filing the original report in the PA list, to see if I could find where the mute LED might be exposed:

Is there an entry for the mute LED in /sys/class/leds?  Doesn't appear so:


  $ ls -1 /sys/class/leds
  mmc0::
  phy0-led
  tpacpi::power
  tpacpi::standby
  tpacpi::thinklight
  tpacpi::thinkvantage
 

Also tried playing with all the LEDs (0 - 15) in /proc/acpi/ibm/led, setting each to "off", "on", and "blink". None of them control the mute LED.

All of the above hold for both 3.18.6 and 3.19.3 kernels.

Created attachment 174161 [details]
Script to invoke hardware mute via hda-verb

http://git.kernel.org/cgit/linux/kernel/git/tiwai/hda-emu.git/commit/?id=05c5a5c32299791083b16d5560b608c91224ffa2


the result was emulated using hda-emu

if your mute led did not turn on , this mean either cannot request symbol tpacpi_led_set fail

or tpacpi_led_set does not turn on mute led



if (!led_set_func)
			led_set_func = symbol_request(tpacpi_led_set);
		if (!led_set_func) {
			codec_warn(codec,
				   "Failed to find thinkpad-acpi symbol tpacpi_led_

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/hda/thinkpad_helper.c

(In reply to G. Golden from comment #16)
> Created attachment 174161 [details]
> Script to invoke hardware mute via hda-verb


https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/core/vmaster.c

change of virtual master playback switch  

master_put
sync_slaves which mute/unmute both slaves speaker and headphone


list_for_each_entry(slave, &master->slaves, list) {
		master->val = old_val;
		uval->id = slave->slave.id;
		slave_get_val(slave, uval);
		master->val = new_val;
		slave_put_val(slave, uval);
	}




static int slave_put_val(struct link_slave *slave,
			 struct snd_ctl_elem_value *ucontrol)
{
	int err, ch, vol;

	err = master_init(slave->master);
	if (err < 0)
		return err;

	switch (slave->info.type) {
	case SNDRV_CTL_ELEM_TYPE_BOOLEAN:
		for (ch = 0; ch < slave->info.count; ch++)
			ucontrol->value.integer.value[ch] &=
				!!slave->master->val;
		break;

return slave->slave.put(&slave->slave, ucontrol);
}



the value of slaves controls are updated

whether alsamixer /pulseaudio notice this change depend on slave->slave.put(&slave->slave, ucontrol)

if you running two instance of alsamixer -c 0

the change of speaker playback volume / switch on one alsa mixer will also update the other alsa mixer

Not sure where to go with what you've posted above. I have essentially zero familiarity with the driver.  I'm more than happy to roll up my sleeves and get involved, but I need more info than what you've supplied above in order to know what you'd like me to do next.

Perhaps it would better to get someone from PA involved? 
 
I did try running two alsamixer -c0 and they do follow each other.  Not sure I  understand the implication of this though, w.r.t. the LED issue. Can you explain a bit more?

seem emulator show  CTL Notify only for change of value of those jack controls

http://git.kernel.org/cgit/linux/kernel/git/tiwai/hda-emu.git/tree/snd-vmaster.c?id=HEAD

static void update_tpacpi_mute_led(void *private_data, int enabled)
{
	if (old_vmaster_hook)
		old_vmaster_hook(private_data, enabled);

	if (led_set_func)
		led_set_func(TPACPI_LED_MUTE, !enabled);
}

 TPACPI_LED_MUTE  is hardcode in update_tpacpi_mute_led()

you can add debug message to dump the value of enabled



do you mean there is no error message in system log when driver call symbol_request when driver is loaded ?


Failed to find thinkpad-acpi symbol tpacpi_led_set

http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/paths

pulseaudio only has dock_mic.conf but no dock_headphone.conf

post output

pactl list sinks

this mean that availablity of speaker is still unknown when the dock headphone jack is plugged and headphone jack is unplugged

seem different from hardware maintenance manual

https://www.kernel.org/doc/Documentation/laptops/thinkpad-acpi.txt


ThinkPads have a built-in amplifier and muting circuit that drives the
console headphone and speakers.  This circuit is after the main AC97
or HDA mixer in the audio path, and under exclusive control of the
firmware.

ThinkPads have three special hotkeys to interact with the console
audio control: volume up, volume down and mute.

It is worth noting that the normal way the mute function works (on
ThinkPads that do not have a "mute LED") is:

1. Press mute to mute.  It will *always* mute, you can press it as
   many times as you want, and the sound will remain mute.

2. Press either volume key to unmute the ThinkPad (it will _not_
   change the volume, it will just unmute).

!All Loaded Modules
!!------------------


thinkpad_acpi


are there any message about led or buttons from thinkpad_acpi in system log when the module is loaded ?

bugzilla-daemon@bugzilla.kernel.org <bugzilla-daemon@bugzilla.kernel.org> [2015-04-16 03:51:10 +0000]:
> https://bugzilla.kernel.org/show_bug.cgi?id=96171
> 

> --- Comment #24 from Raymond <superquad.vortex2@gmail.com> ---
>
> seem different from hardware maintenance manual
> 

You didn't say what you saw in thinkpad_acpi.txt that was "different" from
the hardware manual, so not sure what you're referring to.

But if you're talking about the operation of the buttons, then it is correct:
The text you excerpted (from thinkpad-acpi.txt) describing the button operation
applies only to ThinkPad models WITHOUT a mute LED.  The T-510 has a mute LED,
and the mute button operates as a toggle (because the LED is there to provide
user feedback as to the mute state.)

>
> https://www.kernel.org/doc/Documentation/laptops/thinkpad-acpi.txt
> 
> It is worth noting that the normal way the mute function works (on
> ThinkPads that do not have a "mute LED") is:
>                ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 1. Press mute to mute.  It will *always* mute, you can press it as
>    many times as you want, and the sound will remain mute.
> 
> 2. Press either volume key to unmute the ThinkPad (it will _not_
>    change the volume, it will just unmute).
>

(In reply to Raymond from comment #23)

> post output
> 
> pactl list sinks
> 
>

See attachment "list_sinks.txt"

Created attachment 174191 [details]
Output of "pactl list sinks"

(In reply to Raymond from comment #25)
> !All Loaded Modules
> 
> are there any message about led or buttons from thinkpad_acpi in system log
> when the module is loaded ?
>

I don't see any. But I will do a fresh boot this evening and post the results. Machine is in use now.

Created attachment 174231 [details]
journal/syslog following new boot under 3.19.3

Raymond - see attachment "journal_3.19.txt". This is the systemd journal output right after booting the 3.19.3 kernel.  It was edited only for length and sanitized, but contains all lines that seem to have anything to do with sound system, thinkpad_acpi, or pulseaudio.

All messages from thinkpad_acpi seem ordinary. No sign of complaints about tcacpi_led_set() or anything that looks suspicious.

(In reply to Raymond from comment #23)

> 
> this mean that availablity of speaker is still unknown when the dock
> headphone jack is plugged and headphone jack is unplugged
>

On my system, no dock has ever been used. So the dock mic is never plugged in.

Can you please explain why you are concerned with the plugged/unplugged status of the jacks, and the effect thereof on the availability of the speaker?  I don't understand the relation between this stuff that you're looking at and the problem being reported in the ticket. 

All of the actual mixer-invoked mute functionality on this T-510 works fine with both 3.18 and 3.19 kernels. There is nothing wrong with any aspect of mixer-invoked muting operation, including auto-switching between speakers and headphones when headphones are inserted or withdrawn. All works fine.

The only thing that the ticket is concerned with is the following regression in functionality between 3.18 and 3.19:

   - In 3.18, the mute button is directly fielded by driver, and it toggles a
     builtin HARDWARE speaker mute, and also toggles the mute LED.
   

   - In 3.19, the driver does not handle the mute button (as intended). What is
     missing is that there is no userspace access to either the hardware mute 
     function or to the mute LED. Therefore both of those functionalities
     which were present in 3.18, are lost in 3.19.

Can you explain how the above have anything to do with the recognition of jack insertion events? I'm not appreciating the relationship.

(In reply to Raymond from comment #22)

> 
> you can add debug message to dump the value of enabled
> 

I'm not set up here to build the driver. If setting up a driver build environment is the only way to help you debug this, I can read up on how to go about it, but honestly would prefer to try some other approaches first. For example, would it be possible for you to send me an instrumented kernel module?

Let me know, ok? If you really need me to set up a build environment, can you point me to good document for getting started with it?

Thanks.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=420f9739a62cdb027f5580d25c813501ff93aa6f


whether mute led can be turn on/off depend on whether "SSMS" exist in acpi table

http://www.spinics.net/lists/ibm-acpi-devel/msg03401.html

you should follow up with the developer about the button and led

Simple mixer control 'Auto-Mute Mode',0
  Capabilities: enum
  Items: 'Disabled' 'Enabled'
  Item0: 'Enabled'


the hda driver allow user to disable auto mute mode,  mute/unmute of speaker will be controlled by speaker playback switch on your t510

(In reply to Raymond from comment #35)
> http://www.spinics.net/lists/ibm-acpi-devel/msg03401.html
> 
> you should follow up with the developer about the button and led
>

I'll take it up there, thanks.

http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/WritingVolumeControlUIs/


Presenting Volumes

Generally you should present sliders that ranges from PA_VOLUME_MUTED to PA_VOLUME_NORM, possibly extending it beyond that. For sink inputs that slider should probably show no steps (although in fact you have 65537 steps due to the range of 0..65536 that is PA_VOLUME_MUTED..PA_VOLUME_NORM). 



whether you get back the original volume when you unmute is not clear

Raymond, thanks for your time and help on this. I'm going to take it up further with the thinkpad_acpi folks. 

IMO, the real solution here is to allow userspace control of the hardware-based speaker mute function and the mute LED. That would be an improvement over both 3.18 and present versions of 3.19.  (Even though the 3.19  thinkpad_acpi can be boot-optioned to behave just like 3.18, this is not a real solution to the issue.) 

If userspace control over HW mute and mute LED is possible, it seems to me this would satisfy everyone, as it provides complete flexibility as to how muting is performed (HW or SW) and under what conditions the mute LED comes on in response. With that flexibility, the user (or desktop environment designer) can get any desired mute and LED behavior they like.

Anyway, thanks again for your time Raymond, really appreciate it.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/thinkpad_acpi.c



static int volume_get_status_ec(u8 *status)
{
	u8 s;

	if (!acpi_ec_read(TP_EC_AUDIO, &s))
		return -EIO;

	*status = s;

	dbg_printk(TPACPI_DBG_MIXER, "status 0x%02x\n", s);

	return 0;
}


static int volume_alsa_mute_get(struct snd_kcontrol *kcontrol,
				struct snd_ctl_elem_value *ucontrol)
{
	u8 s;
	int rc;

	rc = volume_get_status(&s);
	if (rc < 0)
		return rc;

	ucontrol->value.integer.value[0] =
				(s & TP_EC_AUDIO_MUTESW_MSK) ? 0 : 1;
	return 0;
}
static struct snd_kcontrol_new volume_alsa_control_mute __initdata = {
	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
	.name = "Console Playback Switch",
	.index = 0,
	.access = SNDRV_CTL_ELEM_ACCESS_READ,
	.info = volume_alsa_mute_info,
	.get = volume_alsa_mute_get,
};


Console Playback Switch is a read only switch

do it follow the mute gate status ?

http://www.spinics.net/lists/ibm-acpi-devel/msg03404.html


http://git.alsa-project.org/?p=alsa-plugins.git;a=blob;f=pulse/ctl_pulse.c;hb=HEAD

the master playback switch and capture switch of pulse plugin mute the sink and source 



                 if (key == 1)
                         o = pa_context_set_source_mute_by_name(ctl->p->
                                                             context,
                                                               ctl->source,
                                                                ctl->
                                                                 source_muted,
                                                                 pulse_context_success_cb,
                                                                 ctl->p);
                else
                          o = pa_context_set_sink_mute_by_name(ctl->p->
                                                               context,
                                                             ctl->sink,
                                                             ctl->
                                                               sink_muted,
                                                               pulse_context_success_cb,
                                                               ctl->p);




http://git.alsa-project.org/?p=alsa-plugins.git;a=blob;f=doc/README-pulse;hb=HEAD


  Both plugins accept the "server" parameter, specifying which PulseAudio server
  to contact. Both also accept the "device" parameter, which indicate which
  source and sink to use.

(In reply to G. Golden from comment #0)
> Please see:
> 
>    http://marc.info/?l=linux-kernel&m=142801293803024
> 

refer to comment in your alsa-info

what is fallback ?


http://git.alsa-project.org/?p=alsa-plugins.git;a=commitdiff;h=5f5cde50d9de7b63aa6f1a7a86c31eeb2a4e9950;hp=826dafa673157b570eacd38e85ca13a3dc7c0c73

fallback will be used when you cannot connect to  pulseaudio server (pa crash or stop)


what is sysdefault ?

http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=e6f990e5c9be5cac6f36924d20a75d0f69d27297;hp=e2c2262403c5639c7ff96f47a43682ff16b7ae4f

(In reply to G. Golden from comment #32)
> (
> 
> Can you please explain why you are concerned with the plugged/unplugged
> status of the jacks, and the effect thereof on the availability of the
> speaker?  I don't understand the relation between this stuff that you're
> looking at and the problem being reported in the ticket. 

https://bugzilla.opensuse.org/show_bug.cgi?id=913686

https://bugzilla.opensuse.org/show_bug.cgi?id=913686#c14

to achieve the priority which is similar to those desktop with internal speaker

the dock headphone need to put in cfg->line_out instead of put both hp in cfg->hp

 some codec prefer to assign DAC to speaker first and both headphone need to share DAC

however desktop which support multistreaming need to avoid sharing DAC between HP and Lineout since different streams can be play to headphone and line out

the auto mute mode control is different if the dock station has dock line out instead of dock headphone

Simple mixer control 'Auto-Mute Mode',0
  Capabilities: enum
  Items: 'Disabled' 'Speaker Only' 'Line Out+Speaker'
  Item0: 'Line Out+Speaker'

Let user know whether the mute led or mic led interface is supported by tpacpi_led_set() when thinkpad_acpi is loaded

static int mute_led_init(struct ibm_init_struct *iibm) { acpi_handle temp; int i;

for (i = 0; i < TPACPI_LED_MAX; i++) {
 struct tp_led_table *t = &led_tables[i];
- if (ACPI_SUCCESS(acpi_get_handle( hkey_handle, t->name, &temp))) 
+ if (ACPI_SUCCESS(acpi_get_handle( hkey_handle, t->name, &temp))) { 
+ pr_info("Thinkpad led %s interface supported.\n", t->name); mute_led_on_off(t, false); 
+ } 
else t->state = -ENODEV; 
} return 0; 
}

Since thinkpad_acpi.c still call tpacpi_hotkey_driver_mask_set( TP_ACPI_HKEY_MUTE_MASK)


	vdbg_printk(TPACPI_DBG_INIT | TPACPI_DBG_MIXER,
		"registering volume hotkeys as change notification\n");
	tpacpi_hotkey_driver_mask_set(hotkey_driver_mask
			| TP_ACPI_HKEY_VOLUP_MASK
			| TP_ACPI_HKEY_VOLDWN_MASK
			| TP_ACPI_HKEY_MUTE_MASK);


http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=9a417ec0c9d1f7af5394333411fc4d98adb8761b





static void tpacpi_driver_event(const unsigned int hkey_event)
{
	if (ibm_backlight_device) {
		switch (hkey_event) {
		case TP_HKEY_EV_BRGHT_UP:
		case TP_HKEY_EV_BRGHT_DOWN:
			tpacpi_brightness_notify_change();
		}
	}
	if (alsa_card) {
		switch (hkey_event) {
		case TP_HKEY_EV_VOL_UP:
		case TP_HKEY_EV_VOL_DOWN:
		case TP_HKEY_EV_VOL_MUTE:
			volume_alsa_notify_change();
		}
	}
+       else {
+             switch(hkey_event) {
+             case TP_HKEY_EV_VOL_MUTE:
+                 pr_info("Mute Button pressed\n");
+             }
+       }
}

Created attachment 175771 [details]
acpidump output, 20150504

As requested by Henrique

Created attachment 175781 [details]
dmidecode output, 20150504

As requested by Henrique