Bug 1034882

I've noticed the same problem docking my X220 as well.  Worked fine in F19, not in F20.

I can confirm this behaviour.

Hardware:
Lenovo ThinkPad T430s
Lenovo ThinkPad Mini Dock Plus Series 3

Since F20, I have to switch the audio output device manually whenever I dock/undock the laptop. With F19 this was done automagically.

(In reply to Stefan Schulze Frielinghaus from comment #2)
> I can confirm this behaviour.
> Since F20, I have to switch the audio output device manually whenever I
> dock/undock the laptop. With F19 this was done automagically.

Ditto, Thinkpad T520, fresh F20 install

I noticed the same after Fedora 20 upgrade on T430s. Regression, it was working fine. Anyone have a clue where to start digging? I do not see any etc updates on PulseAudio after upgrade. Main configuration file seems to be fine and I see the

load-module module-switch-on-port-available

option there.

(In reply to Lukas Zapletal from comment #4)
> Anyone have a clue where to start digging?

I'd try to get some logs from pulseaudio. Run pulseaudio with increased debugging, like this:
 pulseaudio -k ; pulseaudio -vvvvv

Then do the docking/undocking and see in the log how pulseaudio reacts to the events.

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

post output of 

pactl list

Adding my own info:

Alsa-info output: http://www.alsa-project.org/db/?f=4444d39cf1a00bbf91b28ee60cb4504f1cbf4726

Docking station I use: http://support.lenovo.com/en_US/product-and-parts/detail.page?&DocID=PD024298 (Audio ports: Analog microphone in, headphone out)

pactl list cards: http://sprunge.us/jdcJ

the volume controls are at the two audio outputs but there are headphone, dock headphone and speaker pin complexes 

seem a driver bug to support surround-40 when two headphone are not at same location


[    3.596193] ALSA sound/pci/hda/hda_auto_parser.c:393 autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[    3.596194] ALSA sound/pci/hda/hda_auto_parser.c:397    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    3.596195] ALSA sound/pci/hda/hda_auto_parser.c:401    hp_outs=2 (0x15/0x1b/0x0/0x0/0x0)
[    3.596196] ALSA sound/pci/hda/hda_auto_parser.c:402    mono: mono_out=0x0
[    3.596196] ALSA sound/pci/hda/hda_auto_parser.c:406    inputs:
[    3.596198] ALSA sound/pci/hda/hda_auto_parser.c:410      Mic=0x18
[    3.596199] ALSA sound/pci/hda/hda_auto_parser.c:410      Dock Mic=0x19
[    3.596200] ALSA sound/pci/hda/hda_auto_parser.c:410      Internal Mic=0x12



		output:analog-stereo+input:analog-stereo: Analog Stereo Duplex (sinks: 1, sources: 1, priority: 6060, available: yes)
		output:analog-surround-40: Analog Surround 4.0 Output (sinks: 1, sources: 0, priority: 700, available: yes)
		output:analog-surround-40+input:analog-stereo: Analog Surround 4.0 Output + Analog Stereo Input (sinks: 1, sources: 1, priority: 760, available: yes)

	
as the driver already check the status of all headphone jacks to mute/unmute the speaker ,


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

spec->hp_jack_present = detect_jacks(codec, num_pins, pins);


why do pulseaudio need to need to use Jack detection controls ?


did pulseaudio check the status of both headphone jacks to determine the state of the speaker ?


	analog-output-headphones: Headphones (priority: 9000, latency offset: 0 usec, not available)
			Properties:
				device.icon_name = "audio-headphones"
			Part of profile(s): output:analog-stereo, output:analog-stereo+input:analog-stereo

Confirmed on Thinkpad T510 also

Same here with my Thinkpad T420 running a fresh Fedora 20 installation.

I can add that the plugged headset is not recognized as "Headphones", one has to select "Analog output" to redirect the sound to the headset. When manually switching to "Speakers" in this situation, the sound is just muted.

On the other hand, when connecting the headset to the computer audio plug "Speakers" turns into "Headphones" in the sound panel.

if both headphone are connected to same audio output node 0x03 through node 0x0d to share headphone playback volume control, it is a bug of driver if it allow 4 channels since you need both node 0x02 and 0x03 to support surround40

you have to file an upstream bug report


Node 0x15 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Control: name="Headphone Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Headphone Jack", index=0, device=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0001001c: OUT HP EAPD Detect
  EAPD 0x2: EAPD
  Pin Default 0x03211020: [Jack] HP Out at Ext Left
    Conn = 1/8, Color = Black
    DefAssociation = 0x2, Sequence = 0x0
  Pin-ctls: 0xc0: OUT HP
  Unsolicited: tag=01, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 2
     0x0c 0x0d*

Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Control: name="Headphone Playback Switch", index=1, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Dock Headphone Jack", index=0, device=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x00003734: IN OUT Detect
    Vref caps: HIZ 50 GRD 80 100
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT VREF_HIZ
  Unsolicited: tag=02, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 2
     0x0c 0x0d*

I confirm the issue.

When I attach x220 to Mini Dock Plus Series 3, sound disappears.
I have to manually select "Analog Output" or "Headphones (unplugged)" from pavucontrol.

Or I plug headphones to laptop's jack and then sound starts going through dock as well.

It worked perfectly in Fedora 19 and stopped working in Fedora 20.

This feature is important to me.

Thanks!

Is there any workaround? Maybe some change in priorities in configuration files would work?

https://bugs.freedesktop.org/show_bug.cgi?id=84334

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=594da41d07edce

do you mean this patch does not work as expected?

(In reply to Raymond from comment #16)
> https://bugs.freedesktop.org/show_bug.cgi?id=84334
> 
> http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=594da41d07edce
> 
> do you mean this patch does not work as expected?

Hi Raymond!

Is it question to me?

I use the latest pulseaudio availabile in repo for Fedora 20:
pulseaudio-5.0-7.fc20.x86_64

According to its changelog, the last change in it was done in July. So I don't use this patch.

Can you try it and see if it helps?  That patched files are 

/usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf
/usr/share/pulseaudio/alsa-mixer/paths/analog-output-speaker.conf

I presume you'd need to restart pulseaudio for these config changes to take effect? What's the recommended method for doing that?

safest way to do that would be to restart your session (logout/login), else, pulseaudio -k

Thank you Raymond, Rex!

Patches

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=594da41d07edce

applied to

/usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf
/usr/share/pulseaudio/alsa-mixer/paths/analog-output-speaker.conf

resolved the issue!

Excellent, thanks for testing.  I'll look into backporting this fix for an update.

I'm also seeing the problem on my X230 and docking station with Fedora 21.

3.17.7-300.fc21.x86_64

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.