Please see: http://marc.info/?l=linux-kernel&m=142801293803024 Details therein. NOTE: In discussions about this issue on the PulseAudio mailing list, there has been some confusion as to whether it is related to a 3.18 -> 3.19 kernel change in which ThinkPad mute _keys_ were changed from direct driver interrogation (3.18 and earlier) to userspace-controllable softkeys (3.19 an up). To the best of my knowledge, that change is unrelated to the issue reported here. The issue here concerns only the audio output mute LED: The expectation is that the LED should follow the state of the audio output mute function, and does not. The problem was demonstrated (see post) by toggling the mute function via the PulseAudio 'pavucontrol' utility, not via to the mute _keys_, and the expected muting behavior -- no sound! -- was observed.
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