Bug 102501

s/class/sound/hwC0D1/init_pin_configs:
0x14 0x01014010
0x15 0x01011012
0x16 0x01016011
0x17 0x01012014
0x18 0x01a19830
0x19 0x02a19c40
0x1a 0x01813031
0x1b 0x02014c20
0x1c 0x411111f0
0x1d 0x411111f1
0x1e 0x0144111e
0x1f 0x01c46150

/sys/class/sound/hwC0D1/driver_pin_configs:
0x14 0x0121411f
0x15 0x99030120
0x16 0x411111f0
0x17 0x411111f0
0x18 0x411111f0
0x19 0x01a19950
0x1a 0x411111f0
0x1b 0x411111f0
0x1c 0x411111f0
0x1d 0x411111f0
0x1e 0x411111f0

/sys/class/sound/hwC0D1/user_pin_configs:
0x14 0x0121411f
0x15 0x90170150
0x16 0x90170151
0x17 0x411111f0
0x18 0x411111f0
0x19 0x01a19950
0x1a 0x411111f0
0x1b 0x411111f0
0x1c 0x411111f0
0x1d 0x411111f0
0x1e 0x411111f0
0x1f 0x01c46150

the hda auto parser don't like your BIOS pin default which have Line Out at Ext Front and at Ext Rear

there is a PCI quirk which add HP pin with MISC_NO_PRESENCE 


https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/patch/sound/pci/hda/patch_realtek.c?id=ba5338185dd522696f1c0d0957a724a1fdd1f39d


try 

hdajacksensetest -a

to find out whether HP and Mic can be detected when plug and unplug those jacks

(In reply to Raymond from comment #1)
> try 
> 
> hdajacksensetest -a
> 
> to find out whether HP and Mic can be detected when plug and unplug those
> jacks

Thank you for the answer. The HP jack is detected even when I boot without it plugged :

hdajacksensetest -d 1 -a
Pin 0x14 (Green Headphone, Rear side): present = Yes (and No when unplugged)

For the PCI quirk, how can I try it ? Do I have to patch my kernel source and rebuild the sond-hda module or can it be tried by another way.

it is regression by the above patch since unsol event was enabled

you have to clear the bit 8 of pin default of hp pin 

	[ALC880_FIXUP_F1734] = {
		/* almost compatible with FUJITSU, but no bass and SPDIF */
		.type = ALC_FIXUP_PINS,
		.v.pins = (const struct alc_pincfg[]) {
-			{ 0x14, 0x0121411f }, /* HP */
+			{ 0x14, 0x0121401f }, /* HP */

(In reply to Raymond from comment #3)
> it is regression by the above patch since unsol event was enabled
> 
Sorry if I am silly, but what is "unsol"?
If I clear the bit 8 should I expect the subwoofer to work even without a jack plugged at boot, or just expect not needing the hdajackretask boot hack anymore?

Could you try the following two patches, and remove hdajackretask hacks?

Created attachment 184831 [details]
Fix patch #1

Created attachment 184841 [details]
Fix patch #2

(In reply to Jos from comment #4)
> (In reply to Raymond from comment #3)
> > it is regression by the above patch since unsol event was enabled
> > 
> Sorry if I am silly, but what is "unsol"?

-	{0x14, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN|ALC_HP_EVENT},

this mean HP was able to auto mute the speaker before that patch but that patch explicity disable jack detection by set bit 8 which mean no jack detection circuit and driver won't enable unsolicited event any more

(In reply to Takashi Iwai from comment #5)
> Could you try the following two patches, and remove hdajackretask hacks?

I only rebuilt the snd_hda_codec_realtek module.

That activates the subwoofer as did the hdajackretask, except the hardware mixers are different, and I can no longer change the sound level of the subwoofer separately. So this not not as good as hdajackretask hack.

Here is patched result :

http://www.alsa-project.org/db/?f=9d874b76db85f5b69af0ce64d4aa594b553c23e3

And I still need to connect a jack at boot ;-)

Thank you for your attention.

(In reply to Jos from comment #9)
 > That activates the subwoofer as did the hdajackretask, except the hardware
> mixers are different, and I can no longer change the sound level of the
> subwoofer separately. So this not not as good as hdajackretask hack.
> 

Sorry, in fact now Normal speakers are "Surround", and Subwoofer is "Center", so this is a good patch. Will this be OK for other laptops?
Only jack at boot keeps us from the perfection.

It seems that your patched driver didn't get loaded correctly:
[   12.305437] snd_hda_codec_realtek: no symbol version for module_layout
[   12.386171] snd_hda_codec_realtek: no symbol version for module_layout

so the generic parser took over the role, and the result was from the bogus pin configs.  Please retry the build of modules.

[   12.386171] snd_hda_codec_realtek: no symbol version for module_layout
[   12.394850] sound hdaudioC0D1: ignore pin 0x1b with mismatching assoc# 0x2 vs 0x1

you are using bios pin default when snd-hda-codec-realtek module cannot be loaded
the auto parser don't like any line out pin at ext front when there is line out at ext rear


[   12.398292] sound hdaudioC0D1: autoconfig: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
[   12.401649] sound hdaudioC0D1:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   12.405012] sound hdaudioC0D1:    hp_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   12.408327] sound hdaudioC0D1:    mono: mono_out=0x0
[   12.411659] sound hdaudioC0D1:    dig-out=0x1e/0x0
[   12.415044] sound hdaudioC0D1:    inputs:
[   12.422013] sound hdaudioC0D1:      Front Mic=0x19
[   12.425225] sound hdaudioC0D1:      Rear Mic=0x18
[   12.428388] sound hdaudioC0D1:      Line=0x1a
[   12.431532] sound hdaudioC0D1:    dig-in=0x1f

(In reply to Takashi Iwai from comment #11)
> It seems that your patched driver didn't get loaded correctly:
> [   12.305437] snd_hda_codec_realtek: no symbol version for module_layout

I have found that build only a module kills Modules.symlimk file, I could workaround rebuilding the hda whole directory. So now the module is loaded, but the patches do not activate the subwoofer :

http://www.alsa-project.org/db/?f=8a604585993733650b014025f3c030b4b79c33f9

Thanks.

Did you really apply *both* patches?  The alsa-info.sh output indicates that you applied only the first one.

(In reply to Takashi Iwai from comment #14)
> Did you really apply *both* patches?  The alsa-info.sh output indicates that
> you applied only the first one.

OMG you are right. I'm sorry about being so silly following instructions.
Now it still does not work with both patches :

http://www.alsa-project.org/db/?f=37ed17106380e2d26407d0962c7241e7bfad0f4e

Double-check that it's the result of the patched kernel.
When you look at the alsa-info.sh output in the following part:

/sys/class/sound/hwC0D1/driver_pin_configs:
0x14 0x0121401f
0x15 0x99030120
0x16 0x411111f0
0x17 0x411111f0
0x18 0x411111f0
0x19 0x01a19950
0x1a 0x411111f0
0x1b 0x411111f0
0x1c 0x411111f0
0x1d 0x411111f0
0x1e 0x411111f0

You see that 0x16 contains 0x41111111f0.  This must have been changed by the second patch.  You can put some debug message in patch_alc880() to confirm whether you're running the patched code.

> You see that 0x16 contains 0x41111111f0.  This must have been changed by the
> second patch.

Are you sure? I can see any 0x16 modified line by the patches. Anyway, I added some debug info :

[   14.604615] Starting patch_alc880
[   14.608341] sound hdaudioC0D1: autoconfig: line_outs=1 (0x15/0x0/0x0/0x0/0x0) type:speaker
[   14.611886] sound hdaudioC0D1:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   14.615384] sound hdaudioC0D1:    hp_outs=1 (0x14/0x0/0x0/0x0/0x0)
[   14.618919] sound hdaudioC0D1:    mono: mono_out=0x0
[   14.622414] sound hdaudioC0D1:    inputs:
[   14.626359] sound hdaudioC0D1:      Mic=0x19
[   14.629837] sound hdaudioC0D1:    dig-in=0x1f
[   14.636324] err = 1
[   14.639870] Applied patch_alc880

More here : http://www.alsa-project.org/db/?f=fa84d57c49642472509dac7e71f10d2b4595b20a

and I attach the patched file with debug messages to let you double check. Thanks.

Created attachment 186751 [details]
Patched patch_realtek.c file with some debug messages.

The second patch wasn't applied properly.  In your patch_realtek.c the following lines appear:

	SND_PCI_QUIRK(0x1734, 0x107c, "FSC F1734", ALC880_FIXUP_F1734),
	SND_PCI_QUIRK(0x1734, 0x107c, "FSC Amilo M1437", ALC880_FIXUP_FUJITSU),

Since both point to the same ID, the only first one is taken.

The second patch *replaces* the 1734:107c line with the new one (ALC880_FIXUP_FUJITSU).

(In reply to Takashi Iwai from comment #19)
> The second patch wasn't applied properly.  In your patch_realtek.c the

I'm shy. But at least now it works without the hdajackretask hacks.

So now the last question : can I hope any way to get the subwoofer working without having to plug a headphone in the jack at boot.

(In reply to Jos from comment #20)
> So now the last question : can I hope any way to get the subwoofer working
> without having to plug a headphone in the jack at boot.

I didn't follow this part, so far.  Could you tell me what's the exact problem?

you need pulseaudio 7.0 lfe filter (2.1 profile) if your laptop does not have low pass filter ?

do your subwoofer play both left and right channel ?

speaker-test -c4 -twav -D hw:0,0

(In reply to Takashi Iwai from comment #21)
> I didn't follow this part, so far.  Could you tell me what's the exact
> problem?

If the system is booted without something plugged in the jack, no sound comes from the subwoofer, while it still appears in the alsamixer. I somewhat found that plugging anything, then unplugging it after boot completed, activates sound in the subwoofer.

(In reply to Raymond from comment #22)
> you need pulseaudio 7.0 lfe filter (2.1 profile) if your laptop does not
> have low pass filter ?
> 
> do your subwoofer play both left and right channel ?
> 
> speaker-test -c4 -twav -D hw:0,0

It only plays left channel. I suppose this is an hardware limitation?

Created attachment 186801 [details]
alsa-info with jack headphone plugged

Created attachment 186811 [details]
alsa-info without jack headphone plugged at boot

it is strange that pincap is zero


Node 0x16 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out
  Control: name="Bass Speaker Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Speaker Surround Phantom Jack", index=0, device=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x00000000:
  Pin Default 0x01016011: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Orange
    DefAssociation = 0x1, Sequence = 0x1
  Pin-ctls: 0x00:
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x0e

Yeah, something wrong in the hardware level.  Maybe ALC880 is so buggy and the pinctl change screws up the pin setup.

Could you try the patch below in addition?

Created attachment 186821 [details]
Patch to set auto_mute_via_amp flag for ALC880

(In reply to Jos from comment #24)
> (In reply to Raymond from comment #22)
> > you need pulseaudio 7.0 lfe filter (2.1 profile) if your laptop does not
> > have low pass filter ?
> > 
> > do your subwoofer play both left and right channel ?
> > 
> > speaker-test -c4 -twav -D hw:0,0
> 
> It only plays left channel. I suppose this is an hardware limitation?

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=ee81abb623cb5e03c182d16871bb4fb34fdc9b4f

do you mean your laptop need to use customised 2.1 channel map instead of default

const struct snd_pcm_chmap_elem snd_pcm_fujitsu_2_1_chmaps[] = {
+	{ .channels = 2,
+	  .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR } },
+	{ .channels = 4,
+	  .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR,
+		   SNDRV_CHMAP_LFE, SNDRV_CHMAP_NA} },
+	{ }
+};

it is pulseaudio bug to provide surround 4.0 profile which did not check alsa channel map and pulseaudio channel 


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

(In reply to Takashi Iwai from comment #28)
> Yeah, something wrong in the hardware level.  Maybe ALC880 is so buggy and
> the pinctl change screws up the pin setup.
> 
> Could you try the patch below in addition?

Still no subwoofer sound.
http://www.alsa-project.org/db/?f=1f151adb78b2716f90d49ed872407aaa3f4a0ed2

(In reply to Raymond from comment #31)
> it is pulseaudio bug to provide surround 4.0 profile which did not check
> alsa channel map and pulseaudio channel 
> 
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=91471

In fact 4.0 appears in pavucontrol but is not the default choosen. Sorry I don't understand your answer : do you want me to test the patch of the URL in comment 30 ?

(In reply to Jose from comment #32)
> (In reply to Takashi Iwai from comment #28)
> > Yeah, something wrong in the hardware level.  Maybe ALC880 is so buggy and
> > the pinctl change screws up the pin setup.
> > 
> > Could you try the patch below in addition?
> 
> Still no subwoofer sound.
> http://www.alsa-project.org/db/?f=1f151adb78b2716f90d49ed872407aaa3f4a0ed2

OK, then try to boot with snd_hda_intel.probe_only=1 boot option.
This will disable the automatic configuration, so the sound isn't usable at first.  But you'll have the access to /proc/asound/card0/codec#* files, so read them and attach to Bugzilla.  Here the point to check is whether the pin-caps of NID 0x16 is still 0x00.

Suppose you built your kernel with kernel trace feature, try to turn on the tracing of HD-audio events (as root):
  # echo 1 > /sys/kernel/debug/tracing/events/hda

Then configure HD-audio.  Here I assume hwC0D1 (codec#1) is the Realtek one.  If codec#0 is Realtek, use hwC0D0:
  # echo 1 > /sys/class/sound/hwC0D1/reconfig

Read the tracing output
  # cat /sys/kernel/debug/tracing/trace > hda-trace.txt

And attach this output to Bugzilla, too.  Finally, run alsa-info.sh at this moment to be sure to verify the state.

Some details about tracing is found in Documentation/sound/alsa/HD-Audio.txt.

alc880 is the only hda codec which issuse  SET_PIN_SENSE before GET_PIN_SENSE

Do your codec really need SET_PIN_SENSE since it suppose to start impedance measurement which generate noise and event ?


https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=729d55ba972348234759f8e40abf8de020f0d505

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=bfc9902599549736b9c6445e1e2235b8542f64a6

Created attachment 186881 [details]
cat /proc/asound/card0/codec#* without jack headphone plugged

Created attachment 186891 [details]
hda trace of reconfig without plugged headphone

(In reply to Takashi Iwai from comment #34)
> OK, then try to boot with snd_hda_intel.probe_only=1 boot option.
> This will disable the automatic configuration, so the sound isn't usable at
> first.  But you'll have the access to /proc/asound/card0/codec#* files, so
> read them and attach to Bugzilla.  Here the point to check is whether the
> pin-caps of NID 0x16 is still 0x00.

Look like yes, but I let you read the attached file.

> And attach this output to Bugzilla, too.  Finally, run alsa-info.sh at this
> moment to be sure to verify the state.
> 

My Mageia distro comes with trace so yes I got hdatrace.txt, see attached file.
I just tested without headphone plugged at boot, I don't know if it is needed to do with with some thing plugged?

http://www.alsa-project.org/db/?f=0752eb3aacf116d34d45d5c5836471415e026df2

if you can hear high frequency when speaker -test play rear left signal from subwoofer, this mean that your laptop does not have and hardware low oass filter and you need to provide corre ct 2.1 channel map for pulseaudio lfe filter 

those asus laptop external sonic master subwoofer need customised 2.1 channel map 

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=8e38395360844806041ea69ab9690f5f174bc40c


static const struct snd_pcm_chmap_elem asus_pcm_2_1_chmaps[] = {
+	{ .channels = 2,
+	  .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR } },
+	{ .channels = 4,
+	  .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR,
+		   SNDRV_CHMAP_NA, SNDRV_CHMAP_LFE } }, /* LFE only on right */
+	{ }
+};

do your laptop have  knob for changing volume?

Node 0x21 [Volume Knob Widget] wcaps 0x600080: Mono
  Volume-Knob: delta=0, steps=64, direct=0, val=40
  Unsolicited: tag=02, enabled=1
  Connection: 0

(In reply to Raymond from comment #40)
> do your laptop have  knob for changing volume?
> 
> Node 0x21 [Volume Knob Widget] wcaps 0x600080: Mono
>   Volume-Knob: delta=0, steps=64, direct=0, val=40
>   Unsolicited: tag=02, enabled=1
>   Connection: 0

Yes, it has near the 3.5mm jack. This one has the headset logo and /SPDIF, I suppose it can also output digital through this jack?

http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/profile-sets/default.conf


headphone belong to stereo profile

after headphone is plugged,  pulseaudio change from 2.1 profile to stereo

but pulseaudio remain at stereo after headphone is plugged

(In reply to Raymond from comment #42)
> but pulseaudio remain at stereo after headphone is plugged

You mean unplugged? Anyway, I don't understand if you are helping me :

1. getting the subwoofer working without jack plugged at boot?

2. making pulseaudio mix left and right channels in the subwoofer?

Thanks.

7.3.3.15 Pin Sense  

The Pin Sense control returns the Presence Detect status, EDID-Like Data (ELD) Valid, and the impedance measurement of the device attached to the pin.   Some codecs may require that the impedance measurement be triggered by software; in that case, sending the Execute command will cause the impedance measurement to begin.  The “Presence Detect” bit will always be accurate if that functionality is supported by the widget. Note that the Pin Complex Widget may support the generation of an Unsolicited Response to indicate that the Sense Measurement (either the Presence Detect or the Impedance) value has changed, the generation of which implies that the measurement is complete. 


alc880 is the only hda codec which the driver still exec GET_PIN_SENSE before GET_PIN_SENSE as those ADI codecs seem generate event when driver start impedance measurement in an endless loop



* execute pin sense measurement */
static u32 read_pin_sense(struct hda_codec *codec, hda_nid_t nid)
{
	u32 pincap;
	u32 val;

	if (!codec->no_trigger_sense) {
		pincap = snd_hda_query_pin_caps(codec, nid);
		if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
			snd_hda_codec_read(codec, nid, 0,
					AC_VERB_SET_PIN_SENSE, 0);
	}
	val = snd_hda_codec_read(codec, nid, 0,
				  AC_VERB_GET_PIN_SENSE, 0);
	if (codec->inv_jack_detect)
		val ^= AC_PINSENSE_PRESENCE;
	return val;
}

according to hda specification , it only require codec to return PD when receive  GET_PIN_SENSE command

(In reply to Jose from comment #33)
> (In reply to Raymond from comment #31)
> > it is pulseaudio bug to provide surround 4.0 profile which did not check
> > alsa channel map and pulseaudio channel 
> > 
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=91471
> 
> In fact 4.0 appears in pavucontrol but is not the default choosen. Sorry I
> don't understand your answer : do you want me to test the patch of the URL
> in comment 30 ?

http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/pulse/channelmap.c

there is no useful function to compare alsa driver's channel map with pulseaudio channel map from pulseaudio default.conf


especially when pulseaudio 2.1 profile can be mapped to several alsa 2.1 channel maps including 5.1

http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=48f1b308cc66152eb6db66742dd0d08d888cda8d;hp=5c4cd46810cef8850b037fca9e38ffd43b0bff22

(In reply to Jose from comment #38)
> (In reply to Takashi Iwai from comment #34)
> > OK, then try to boot with snd_hda_intel.probe_only=1 boot option.
> > This will disable the automatic configuration, so the sound isn't usable at
> > first.  But you'll have the access to /proc/asound/card0/codec#* files, so
> > read them and attach to Bugzilla.  Here the point to check is whether the
> > pin-caps of NID 0x16 is still 0x00.
> 
> Look like yes, but I let you read the attached file.

Thanks, it's indeed 0x00, so the initial state is already bogus.
It's found not only on NID 0x16 but also 0x17.
 
> > And attach this output to Bugzilla, too.  Finally, run alsa-info.sh at this
> > moment to be sure to verify the state.
> > 
> 
> My Mageia distro comes with trace so yes I got hdatrace.txt, see attached
> file.
> I just tested without headphone plugged at boot, I don't know if it is
> needed to do with with some thing plugged?
> 
> http://www.alsa-project.org/db/?f=0752eb3aacf116d34d45d5c5836471415e026df2

That's the requested information.  But it'd be also helpful to have these information with the hp-plugged boot.  Especially to see whether NID 0x16 has a right value when booted with hp plugged, even with probe_only=1.

Another test I'd like to ask it to the manual adjustment of the pin 0x16.
Boot without HP as normal, that is, keep the broken state.  Confirm /proc/asound/card0/codec#1 wheter NID 0x16 Pincap and Pin-ctls are both 0.  Then, run hda-verb like:

  hda-verb /dev/snd/hwC0D1 0x16 SET_PIN_WID 0x40

and check the proc file again whether the pin-ctls is changed or not.

If it doesn't change, it's really a hardware problem, likely a bug of ALC880 chip design.  There can be some workaround, but it's hard to know...

(In reply to Takashi Iwai from comment #47)
> That's the requested information.  But it'd be also helpful to have these
> information with the hp-plugged boot.  Especially to see whether NID 0x16
> has a right value when booted with hp plugged, even with probe_only=1.

I attach the whole dump, but yes NID 0x16 has the good value even with probe_only=1.

> Another test I'd like to ask it to the manual adjustment of the pin 0x16.
> Boot without HP as normal, that is, keep the broken state.  Confirm
> /proc/asound/card0/codec#1 wheter NID 0x16 Pincap and Pin-ctls are both 0. 
> Then, run hda-verb like:
> 
>   hda-verb /dev/snd/hwC0D1 0x16 SET_PIN_WID 0x40
> 
> and check the proc file again whether the pin-ctls is changed or not.
> 
> If it doesn't change, it's really a hardware problem, likely a bug of ALC880
> chip design.  There can be some workaround, but it's hard to know...

Unfortunately, it does not change. Thank you  for spending time, of course I can live with this bug, let's keep it under the carpet ;-)

Will the fix patch #1 and #2 end in the mainline kernel?

Created attachment 187091 [details]
cat /proc/asound/card0/codec#1 with jack headphone plugged

why the name of codec is "not set" ?


Codec: Not Set
Address: 1
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x10ec0880
Subsystem Id: 0x08800000
Revision Id: 0x100800
No Modem Function Group found

(In reply to Jose from comment #49)
> Created attachment 187091 [details]
> cat /proc/asound/card0/codec#1 with jack headphone plugged

Node 0x21 [Volume Knob Widget] wcaps 0x600080: Mono
  Volume-Knob: delta=0, steps=64, direct=0, val=46
  Unsolicited: tag=00, enabled=0
  Connection: 0

it is strange that unsolicited event was not always enabled

Just because it's the result of pre-probe.

static u32 read_pin_sense(struct hda_codec *codec, hda_nid_t nid)
{
	u32 pincap;
	u32 val;

-	if (!codec->no_trigger_sense) {
-		pincap = snd_hda_query_pin_caps(codec, nid);
-		if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
-			snd_hda_codec_read(codec, nid, 0,
-					AC_VERB_SET_PIN_SENSE, 0);
-	}
	val = snd_hda_codec_read(codec, nid, 0,
				  AC_VERB_GET_PIN_SENSE, 0);
	if (codec->inv_jack_detect)
		val ^= AC_PINSENSE_PRESENCE;
	return val;
}

do alc880 really need snd_hda_codec_read(codec, nid, 0,				AC_VERB_SET_PIN_SENSE, 0); ?

(In reply to Raymond from comment #53)
> static u32 read_pin_sense(struct hda_codec *codec, hda_nid_t nid)
> .....
> do alc880 really need snd_hda_codec_read(codec, nid, 0,                       
> AC_VERB_SET_PIN_SENSE, 0); ?

Is this a patch to try?

is it possible to post the trace when you plug headphone since the driver start impedance measurement which take time to complete ?




Impedance returns the measured impedance of the widget.  A returned value of 0x7FFF,FFFF (all 1‟s) indicates that a valid sense reading is not available, or the sense measurement is busy (refer to Section 7.3.1) if it has been recently triggered.  This field is only valid if the widget has Sense capability as indicated by the “Impedance Sense Capable” bit of the Pin Capabilities parameter.

http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=hdajacksensetest/hdajacksensetest.c;hb=HEAD

hdajacksensetest can be modified to show the impedance when you specify setpinsense



	if (set_pin_sense) {
		for (i = 0; i < pin_count; i++)
			if (should_check_pin(&pin_configs[i])) {
				codec_rw(pin_configs[i].nid, AC_VERB_SET_PIN_SENSE, 0);
			}
		sleep(1);
	}

	for (i = 0; i < pin_count; i++)
		if (should_check_pin(&pin_configs[i])) {
			gchar *desc = get_config_description(actual_pin_config(&pin_configs[i]));
			unsigned long present = codec_rw(pin_configs[i].nid, AC_VERB_GET_PIN_SENSE, 0);
-			printf("Pin 0x%.2x (%s): present = %s\n", pin_configs[i].nid, desc, present & 0x80000000 ? "Yes" : "No");
+        printf("Pin 0x%.2x (%s): present = %x\n", pin_configs[i].nid, desc, present );
			g_free(desc);
		}

The subwoofer works with a headset plugged at power-on. While this is not a good fix, it is enough for me.