Re: realtek ALC272 support

Re: realtek ALC272 support

[Andres Salomon]

On Tue, 28 Apr 2009 15:41:08 -0400
Andres Salomon <dilinger@queued.net> wrote:

> On Mon, 27 Apr 2009 18:08:21 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
[...]
> > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > Andres Salomon wrote:
> > > > > > > > > 
> > > > > > > > > Hi Kailang,
> > > > > > > > > 
> > > > > > > > > I noticed that your name was on the ALC272 support
> > > > > > > > > patch for ALSA intel-hda.  This patch basically sets
> > > > > > > > > ALC272 to use (mostly) the same code as ALC662.  I
> > > > > > > > > have two machines that have ALC272, and both of them
> > > > > > > > > need verb tables in order to function.  I'm wondering
> > > > > > > > > if ALC662 should really be used..
> > > > > > > > > 
> > > > > > > > > Here's one -
> > > > > > > > > 
> > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > 
> > > > > > > > > This isn't the final version of the patch (there are
> > > > > > > > > further commits I made in order to support headphone
> > > > > > > > > mic stuff), but it gives you an idea of the codec
> > > > > > > > > values. The other is:
> > > > > > > > > 
> > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > 
> > > > > > > > > All of these leave me wonder if there's a specific
> > > > > > > > > patch_alc272 function that could be written to rid
> > > > > > > > > ourselves of these specific quirks.  Are there
> > > > > > > > > machines with ALC272 that are functional with the
> > > > > > > > > current ALSA code?
> > > > > > > > 
[...]
> > 
> > Could you try sound-unstable tree a bit later again?
> > I found a bug in my patch, and fixed and updated GIT tree now.
> > At least, the headphone plugging should work now.
> > 
> > The mic auto-detection still doesn't work with model=auto, though.
> > So, I'm going to take your patch anyway later.  But I just wanted
> > to be sure that the current tree could work somehow better...
> > 
> 
> Hi,
> 
> I just updated and tried the current tree; still no sound/headphone
> output.  :(


Ok, I believe I've made some progress on this.  The problem appears to
be related to the autoconfig handling of the line out nids.  The
current code ends up with something like the following:

ALSA sound/pci/hda/hda_codec.c:3833: autoconfig: line_outs=1
(0x17/0x0/0x0/0x0/0x0)
ALSA sound/pci/hda/hda_codec.c:3837:    speaker_outs=0
(0x0/0x0/0x0/0x0/0x0)
ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
ALSA sound/pci/hda/hda_codec.c:3842:    mono: mono_out=0x0
ALSA sound/pci/hda/hda_codec.c:3853: inputs: mic=0x18, fmic=0x19,
line=0x0, fline=0x0, cd=0x0, aux=0x0

However, NID 0x17 is actually a speaker_out.  The code that checks for
line_outs in snd_hda_parse_pin_def_config() unsets the speaker_out and
uses that NID for a line_out.  For whatever reason, this breaks things
(no sound output, no headphone out).


According to the ALC272 data sheet (the block diagram on page 5),
there are actually 2 line_out NIDs; 0x14 and 0x15.  The default pin
configs for these two NIDs (0x411111f0 for both) have the Port
Connectivity field set to AC_JACK_PORT_NONE, so the auto-config skips
those NIDs.

If I provide an override to a) set Port Connectivity to
AC_JACK_PORT_COMPLEX, and b) set Default Device to AC_JACK_LINE_OUT
(from AC_JACK_SPEAKER), I get usable audio (speakers work,
headphone works, headphone plugging mutes the speaker properly, and
even the mic works).  The patch which I've used is below.

Clearly, this isn't a very nice solution, so the question is:
is there a way to provide an override/quirk for pincfgs (I see one for
HWDEP, but that's configuration-specific) within the current hda_codec
framework for this specific codec/laptop?  Alternatively, I can try and
figure out what's wrong with the code in the case where
line_out_pins[0] is set to the speaker_out_pins[0] (ie, NID 0x17 in
this case).  

I can check the other ALC272 machine tomorrow (the DELL_ZM1) to see if
the line_out hack enables it to work without the verb table.




diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index b91f6ed..5aa7a0c 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -3644,6 +3644,15 @@ int snd_hda_parse_pin_def_config(struct hda_codec *codec,
 			continue;
 
 		def_conf = snd_hda_codec_get_pincfg(codec, nid);
+		snd_printd("nid %x: pincfg def_conf=%x\n", nid, def_conf);
+		if (codec->vendor_id == 0x10ec0272 &&
+				(nid == 0x14 || nid == 0x15)) {
+			def_conf &= ~(0x3 << AC_DEFCFG_PORT_CONN_SHIFT);
+			def_conf &= ~(0xf << AC_DEFCFG_DEVICE_SHIFT);
+			snd_printd("nid %x: overriding def_conf, now %x\n", nid,
+					def_conf);
+		}
+
 		if (get_defcfg_connect(def_conf) == AC_JACK_PORT_NONE)
 			continue;
 		loc = get_defcfg_location(def_conf);

Re: realtek ALC272 support

[Takashi Iwai]

At Tue, 28 Apr 2009 18:21:55 -0400,
Andres Salomon wrote:
> 
> On Tue, 28 Apr 2009 15:41:08 -0400
> Andres Salomon <dilinger@queued.net> wrote:
> 
> > On Mon, 27 Apr 2009 18:08:21 +0200
> > Takashi Iwai <tiwai@suse.de> wrote:
> > 
> [...]
> > > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > 
> > > > > > > > > > Hi Kailang,
> > > > > > > > > > 
> > > > > > > > > > I noticed that your name was on the ALC272 support
> > > > > > > > > > patch for ALSA intel-hda.  This patch basically sets
> > > > > > > > > > ALC272 to use (mostly) the same code as ALC662.  I
> > > > > > > > > > have two machines that have ALC272, and both of them
> > > > > > > > > > need verb tables in order to function.  I'm wondering
> > > > > > > > > > if ALC662 should really be used..
> > > > > > > > > > 
> > > > > > > > > > Here's one -
> > > > > > > > > > 
> > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > 
> > > > > > > > > > This isn't the final version of the patch (there are
> > > > > > > > > > further commits I made in order to support headphone
> > > > > > > > > > mic stuff), but it gives you an idea of the codec
> > > > > > > > > > values. The other is:
> > > > > > > > > > 
> > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > 
> > > > > > > > > > All of these leave me wonder if there's a specific
> > > > > > > > > > patch_alc272 function that could be written to rid
> > > > > > > > > > ourselves of these specific quirks.  Are there
> > > > > > > > > > machines with ALC272 that are functional with the
> > > > > > > > > > current ALSA code?
> > > > > > > > > 
> [...]
> > > 
> > > Could you try sound-unstable tree a bit later again?
> > > I found a bug in my patch, and fixed and updated GIT tree now.
> > > At least, the headphone plugging should work now.
> > > 
> > > The mic auto-detection still doesn't work with model=auto, though.
> > > So, I'm going to take your patch anyway later.  But I just wanted
> > > to be sure that the current tree could work somehow better...
> > > 
> > 
> > Hi,
> > 
> > I just updated and tried the current tree; still no sound/headphone
> > output.  :(
> 
> 
> Ok, I believe I've made some progress on this.  The problem appears to
> be related to the autoconfig handling of the line out nids.  The
> current code ends up with something like the following:
> 
> ALSA sound/pci/hda/hda_codec.c:3833: autoconfig: line_outs=1
> (0x17/0x0/0x0/0x0/0x0)
> ALSA sound/pci/hda/hda_codec.c:3837:    speaker_outs=0
> (0x0/0x0/0x0/0x0/0x0)
> ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
> ALSA sound/pci/hda/hda_codec.c:3842:    mono: mono_out=0x0
> ALSA sound/pci/hda/hda_codec.c:3853: inputs: mic=0x18, fmic=0x19,
> line=0x0, fline=0x0, cd=0x0, aux=0x0
> 
> However, NID 0x17 is actually a speaker_out.  The code that checks for
> line_outs in snd_hda_parse_pin_def_config() unsets the speaker_out and
> uses that NID for a line_out.  For whatever reason, this breaks things
> (no sound output, no headphone out).

That's intentional, and the driver checks that case, too.
Please check the latest sound git tree and see the kernel message.
You should have messages like "realtek: ..."


Takashi

Re: realtek ALC272 support

[Andres Salomon]

On Wed, 29 Apr 2009 08:33:28 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Tue, 28 Apr 2009 18:21:55 -0400,
> Andres Salomon wrote:
> > 
> > On Tue, 28 Apr 2009 15:41:08 -0400
> > Andres Salomon <dilinger@queued.net> wrote:
> > 
> > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > Takashi Iwai <tiwai@suse.de> wrote:
> > > 
> > [...]
> > > > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > 
> > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > 
> > > > > > > > > > > I noticed that your name was on the ALC272 support
> > > > > > > > > > > patch for ALSA intel-hda.  This patch basically
> > > > > > > > > > > sets ALC272 to use (mostly) the same code as
> > > > > > > > > > > ALC662.  I have two machines that have ALC272,
> > > > > > > > > > > and both of them need verb tables in order to
> > > > > > > > > > > function.  I'm wondering if ALC662 should really
> > > > > > > > > > > be used..
> > > > > > > > > > > 
> > > > > > > > > > > Here's one -
> > > > > > > > > > > 
> > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > 
> > > > > > > > > > > This isn't the final version of the patch (there
> > > > > > > > > > > are further commits I made in order to support
> > > > > > > > > > > headphone mic stuff), but it gives you an idea of
> > > > > > > > > > > the codec values. The other is:
> > > > > > > > > > > 
> > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > 
> > > > > > > > > > > All of these leave me wonder if there's a specific
> > > > > > > > > > > patch_alc272 function that could be written to rid
> > > > > > > > > > > ourselves of these specific quirks.  Are there
> > > > > > > > > > > machines with ALC272 that are functional with the
> > > > > > > > > > > current ALSA code?
> > > > > > > > > > 
> > [...]
> > > > 
> > > > Could you try sound-unstable tree a bit later again?
> > > > I found a bug in my patch, and fixed and updated GIT tree now.
> > > > At least, the headphone plugging should work now.
> > > > 
> > > > The mic auto-detection still doesn't work with model=auto,
> > > > though. So, I'm going to take your patch anyway later.  But I
> > > > just wanted to be sure that the current tree could work somehow
> > > > better...
> > > > 
> > > 
> > > Hi,
> > > 
> > > I just updated and tried the current tree; still no
> > > sound/headphone output.  :(
> > 
> > 
> > Ok, I believe I've made some progress on this.  The problem appears
> > to be related to the autoconfig handling of the line out nids.  The
> > current code ends up with something like the following:
> > 
> > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig: line_outs=1
> > (0x17/0x0/0x0/0x0/0x0)
> > ALSA sound/pci/hda/hda_codec.c:3837:    speaker_outs=0
> > (0x0/0x0/0x0/0x0/0x0)
> > ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1
> > (0x21/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:3842:
> > mono: mono_out=0x0 ALSA sound/pci/hda/hda_codec.c:3853: inputs:
> > mic=0x18, fmic=0x19, line=0x0, fline=0x0, cd=0x0, aux=0x0
> > 
> > However, NID 0x17 is actually a speaker_out.  The code that checks
> > for line_outs in snd_hda_parse_pin_def_config() unsets the
> > speaker_out and uses that NID for a line_out.  For whatever reason,
> > this breaks things (no sound output, no headphone out).
> 
> That's intentional, and the driver checks that case, too.
> Please check the latest sound git tree and see the kernel message.
> You should have messages like "realtek: ..."
> 
> 
> Takashi


The realtek: lines don't appear to affect NID 0x17 at all.  Instead,
they say:

ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No valid SSID, checking pincfg 0x40178e2d for NID 0x1d
ALSA sound/pci/hda/patch_realtek.c:1170: realtek: Enabling init ASM_ID=0x8e2d CODEC_ID=10ec0272
ALSA sound/pci/hda/patch_realtek.c:1111: realtek: Enable HP auto-muting on NID 0x21

And, as I said, I get no sound output with this..

Re: realtek ALC272 support

[Takashi Iwai]

At Wed, 29 Apr 2009 09:02:41 -0400,
Andres Salomon wrote:
> 
> On Wed, 29 Apr 2009 08:33:28 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Tue, 28 Apr 2009 18:21:55 -0400,
> > Andres Salomon wrote:
> > > 
> > > On Tue, 28 Apr 2009 15:41:08 -0400
> > > Andres Salomon <dilinger@queued.net> wrote:
> > > 
> > > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > 
> > > [...]
> > > > > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > > 
> > > > > > > > > > > > I noticed that your name was on the ALC272 support
> > > > > > > > > > > > patch for ALSA intel-hda.  This patch basically
> > > > > > > > > > > > sets ALC272 to use (mostly) the same code as
> > > > > > > > > > > > ALC662.  I have two machines that have ALC272,
> > > > > > > > > > > > and both of them need verb tables in order to
> > > > > > > > > > > > function.  I'm wondering if ALC662 should really
> > > > > > > > > > > > be used..
> > > > > > > > > > > > 
> > > > > > > > > > > > Here's one -
> > > > > > > > > > > > 
> > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > > 
> > > > > > > > > > > > This isn't the final version of the patch (there
> > > > > > > > > > > > are further commits I made in order to support
> > > > > > > > > > > > headphone mic stuff), but it gives you an idea of
> > > > > > > > > > > > the codec values. The other is:
> > > > > > > > > > > > 
> > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > > 
> > > > > > > > > > > > All of these leave me wonder if there's a specific
> > > > > > > > > > > > patch_alc272 function that could be written to rid
> > > > > > > > > > > > ourselves of these specific quirks.  Are there
> > > > > > > > > > > > machines with ALC272 that are functional with the
> > > > > > > > > > > > current ALSA code?
> > > > > > > > > > > 
> > > [...]
> > > > > 
> > > > > Could you try sound-unstable tree a bit later again?
> > > > > I found a bug in my patch, and fixed and updated GIT tree now.
> > > > > At least, the headphone plugging should work now.
> > > > > 
> > > > > The mic auto-detection still doesn't work with model=auto,
> > > > > though. So, I'm going to take your patch anyway later.  But I
> > > > > just wanted to be sure that the current tree could work somehow
> > > > > better...
> > > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > I just updated and tried the current tree; still no
> > > > sound/headphone output.  :(
> > > 
> > > 
> > > Ok, I believe I've made some progress on this.  The problem appears
> > > to be related to the autoconfig handling of the line out nids.  The
> > > current code ends up with something like the following:
> > > 
> > > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig: line_outs=1
> > > (0x17/0x0/0x0/0x0/0x0)
> > > ALSA sound/pci/hda/hda_codec.c:3837:    speaker_outs=0
> > > (0x0/0x0/0x0/0x0/0x0)
> > > ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1
> > > (0x21/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:3842:
> > > mono: mono_out=0x0 ALSA sound/pci/hda/hda_codec.c:3853: inputs:
> > > mic=0x18, fmic=0x19, line=0x0, fline=0x0, cd=0x0, aux=0x0
> > > 
> > > However, NID 0x17 is actually a speaker_out.  The code that checks
> > > for line_outs in snd_hda_parse_pin_def_config() unsets the
> > > speaker_out and uses that NID for a line_out.  For whatever reason,
> > > this breaks things (no sound output, no headphone out).
> > 
> > That's intentional, and the driver checks that case, too.
> > Please check the latest sound git tree and see the kernel message.
> > You should have messages like "realtek: ..."
> > 
> > 
> > Takashi
> 
> 
> The realtek: lines don't appear to affect NID 0x17 at all.  Instead,
> they say:
> 
> ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No valid SSID, checking pincfg 0x40178e2d for NID 0x1d
> ALSA sound/pci/hda/patch_realtek.c:1170: realtek: Enabling init ASM_ID=0x8e2d CODEC_ID=10ec0272
> ALSA sound/pci/hda/patch_realtek.c:1111: realtek: Enable HP auto-muting on NID 0x21

Then 0x17 should be toggled when the jack on 0x21 is detected.


Takashi

Re: realtek ALC272 support

[Andres Salomon]

On Wed, 29 Apr 2009 15:09:20 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Wed, 29 Apr 2009 09:02:41 -0400,
> Andres Salomon wrote:
> > 
> > On Wed, 29 Apr 2009 08:33:28 +0200
> > Takashi Iwai <tiwai@suse.de> wrote:
> > 
> > > At Tue, 28 Apr 2009 18:21:55 -0400,
> > > Andres Salomon wrote:
> > > > 
> > > > On Tue, 28 Apr 2009 15:41:08 -0400
> > > > Andres Salomon <dilinger@queued.net> wrote:
> > > > 
> > > > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > 
> > > > [...]
> > > > > > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I noticed that your name was on the ALC272
> > > > > > > > > > > > > support patch for ALSA intel-hda.  This patch
> > > > > > > > > > > > > basically sets ALC272 to use (mostly) the
> > > > > > > > > > > > > same code as ALC662.  I have two machines
> > > > > > > > > > > > > that have ALC272, and both of them need verb
> > > > > > > > > > > > > tables in order to function.  I'm wondering
> > > > > > > > > > > > > if ALC662 should really be used..
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Here's one -
> > > > > > > > > > > > > 
> > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > > > 
> > > > > > > > > > > > > This isn't the final version of the patch
> > > > > > > > > > > > > (there are further commits I made in order to
> > > > > > > > > > > > > support headphone mic stuff), but it gives
> > > > > > > > > > > > > you an idea of the codec values. The other is:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > > > 
> > > > > > > > > > > > > All of these leave me wonder if there's a
> > > > > > > > > > > > > specific patch_alc272 function that could be
> > > > > > > > > > > > > written to rid ourselves of these specific
> > > > > > > > > > > > > quirks.  Are there machines with ALC272 that
> > > > > > > > > > > > > are functional with the current ALSA code?
> > > > > > > > > > > > 
> > > > [...]
> > > > > > 
> > > > > > Could you try sound-unstable tree a bit later again?
> > > > > > I found a bug in my patch, and fixed and updated GIT tree
> > > > > > now. At least, the headphone plugging should work now.
> > > > > > 
> > > > > > The mic auto-detection still doesn't work with model=auto,
> > > > > > though. So, I'm going to take your patch anyway later.  But
> > > > > > I just wanted to be sure that the current tree could work
> > > > > > somehow better...
> > > > > > 
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I just updated and tried the current tree; still no
> > > > > sound/headphone output.  :(
> > > > 
> > > > 
> > > > Ok, I believe I've made some progress on this.  The problem
> > > > appears to be related to the autoconfig handling of the line
> > > > out nids.  The current code ends up with something like the
> > > > following:
> > > > 
> > > > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig: line_outs=1
> > > > (0x17/0x0/0x0/0x0/0x0)
> > > > ALSA sound/pci/hda/hda_codec.c:3837:    speaker_outs=0
> > > > (0x0/0x0/0x0/0x0/0x0)
> > > > ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1
> > > > (0x21/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:3842:
> > > > mono: mono_out=0x0 ALSA sound/pci/hda/hda_codec.c:3853: inputs:
> > > > mic=0x18, fmic=0x19, line=0x0, fline=0x0, cd=0x0, aux=0x0
> > > > 
> > > > However, NID 0x17 is actually a speaker_out.  The code that
> > > > checks for line_outs in snd_hda_parse_pin_def_config() unsets
> > > > the speaker_out and uses that NID for a line_out.  For whatever
> > > > reason, this breaks things (no sound output, no headphone out).
> > > 
> > > That's intentional, and the driver checks that case, too.
> > > Please check the latest sound git tree and see the kernel message.
> > > You should have messages like "realtek: ..."
> > > 
> > > 
> > > Takashi
> > 
> > 
> > The realtek: lines don't appear to affect NID 0x17 at all.  Instead,
> > they say:
> > 
> > ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No valid SSID,
> > checking pincfg 0x40178e2d for NID 0x1d ALSA
> > sound/pci/hda/patch_realtek.c:1170: realtek: Enabling init
> > ASM_ID=0x8e2d CODEC_ID=10ec0272 ALSA
> > sound/pci/hda/patch_realtek.c:1111: realtek: Enable HP auto-muting
> > on NID 0x21
> 
> Then 0x17 should be toggled when the jack on 0x21 is detected.
> 
> 
> Takashi

But since I get absolutely no sound through headphones or speakers, I
can't tell if it's being toggled.  :)

I've noticed:
 - in order to get speaker output, 0x17 *must* be defined as the
speaker-out, and 0x14 *must* be listed as a line-out pin.
 - in order to get headphone output, neither 0x17 nor 0x15 are to be
listed as the first line-out pin

Can you please provide a suggestion for how this is supposed to work?
Note that I only have access to this machine for another day.

Re: realtek ALC272 support

[Takashi Iwai]

At Wed, 29 Apr 2009 13:01:42 -0400,
Andres Salomon wrote:
> 
> On Wed, 29 Apr 2009 15:09:20 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Wed, 29 Apr 2009 09:02:41 -0400,
> > Andres Salomon wrote:
> > > 
> > > On Wed, 29 Apr 2009 08:33:28 +0200
> > > Takashi Iwai <tiwai@suse.de> wrote:
> > > 
> > > > At Tue, 28 Apr 2009 18:21:55 -0400,
> > > > Andres Salomon wrote:
> > > > > 
> > > > > On Tue, 28 Apr 2009 15:41:08 -0400
> > > > > Andres Salomon <dilinger@queued.net> wrote:
> > > > > 
> > > > > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > 
> > > > > [...]
> > > > > > > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I noticed that your name was on the ALC272
> > > > > > > > > > > > > > support patch for ALSA intel-hda.  This patch
> > > > > > > > > > > > > > basically sets ALC272 to use (mostly) the
> > > > > > > > > > > > > > same code as ALC662.  I have two machines
> > > > > > > > > > > > > > that have ALC272, and both of them need verb
> > > > > > > > > > > > > > tables in order to function.  I'm wondering
> > > > > > > > > > > > > > if ALC662 should really be used..
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Here's one -
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > This isn't the final version of the patch
> > > > > > > > > > > > > > (there are further commits I made in order to
> > > > > > > > > > > > > > support headphone mic stuff), but it gives
> > > > > > > > > > > > > > you an idea of the codec values. The other is:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > All of these leave me wonder if there's a
> > > > > > > > > > > > > > specific patch_alc272 function that could be
> > > > > > > > > > > > > > written to rid ourselves of these specific
> > > > > > > > > > > > > > quirks.  Are there machines with ALC272 that
> > > > > > > > > > > > > > are functional with the current ALSA code?
> > > > > > > > > > > > > 
> > > > > [...]
> > > > > > > 
> > > > > > > Could you try sound-unstable tree a bit later again?
> > > > > > > I found a bug in my patch, and fixed and updated GIT tree
> > > > > > > now. At least, the headphone plugging should work now.
> > > > > > > 
> > > > > > > The mic auto-detection still doesn't work with model=auto,
> > > > > > > though. So, I'm going to take your patch anyway later.  But
> > > > > > > I just wanted to be sure that the current tree could work
> > > > > > > somehow better...
> > > > > > > 
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > I just updated and tried the current tree; still no
> > > > > > sound/headphone output.  :(
> > > > > 
> > > > > 
> > > > > Ok, I believe I've made some progress on this.  The problem
> > > > > appears to be related to the autoconfig handling of the line
> > > > > out nids.  The current code ends up with something like the
> > > > > following:
> > > > > 
> > > > > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig: line_outs=1
> > > > > (0x17/0x0/0x0/0x0/0x0)
> > > > > ALSA sound/pci/hda/hda_codec.c:3837:    speaker_outs=0
> > > > > (0x0/0x0/0x0/0x0/0x0)
> > > > > ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1
> > > > > (0x21/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:3842:
> > > > > mono: mono_out=0x0 ALSA sound/pci/hda/hda_codec.c:3853: inputs:
> > > > > mic=0x18, fmic=0x19, line=0x0, fline=0x0, cd=0x0, aux=0x0
> > > > > 
> > > > > However, NID 0x17 is actually a speaker_out.  The code that
> > > > > checks for line_outs in snd_hda_parse_pin_def_config() unsets
> > > > > the speaker_out and uses that NID for a line_out.  For whatever
> > > > > reason, this breaks things (no sound output, no headphone out).
> > > > 
> > > > That's intentional, and the driver checks that case, too.
> > > > Please check the latest sound git tree and see the kernel message.
> > > > You should have messages like "realtek: ..."
> > > > 
> > > > 
> > > > Takashi
> > > 
> > > 
> > > The realtek: lines don't appear to affect NID 0x17 at all.  Instead,
> > > they say:
> > > 
> > > ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No valid SSID,
> > > checking pincfg 0x40178e2d for NID 0x1d ALSA
> > > sound/pci/hda/patch_realtek.c:1170: realtek: Enabling init
> > > ASM_ID=0x8e2d CODEC_ID=10ec0272 ALSA
> > > sound/pci/hda/patch_realtek.c:1111: realtek: Enable HP auto-muting
> > > on NID 0x21
> > 
> > Then 0x17 should be toggled when the jack on 0x21 is detected.
> > 
> > 
> > Takashi
> 
> But since I get absolutely no sound through headphones or speakers, I
> can't tell if it's being toggled.  :)

You can see the 0x17 in the codec proc whether it's changed at plugged
/ unplugged.  The driver should change its pin control dynamically.

> I've noticed:
>  - in order to get speaker output, 0x17 *must* be defined as the
> speaker-out, and 0x14 *must* be listed as a line-out pin.
>  - in order to get headphone output, neither 0x17 nor 0x15 are to be
> listed as the first line-out pin

Then it implies that 0x17 has nothing to do with the speaker, i.e. a
BIOS bug.  0x14 could be the speaker output while 0x17 is just a
dummy.


Takashi

Re: realtek ALC272 support

[Andres Salomon]

On Thu, 30 Apr 2009 07:34:02 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Wed, 29 Apr 2009 13:01:42 -0400,
> Andres Salomon wrote:
> > 
> > On Wed, 29 Apr 2009 15:09:20 +0200
> > Takashi Iwai <tiwai@suse.de> wrote:
> > 
> > > At Wed, 29 Apr 2009 09:02:41 -0400,
> > > Andres Salomon wrote:
> > > > 
> > > > On Wed, 29 Apr 2009 08:33:28 +0200
> > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > 
> > > > > At Tue, 28 Apr 2009 18:21:55 -0400,
> > > > > Andres Salomon wrote:
> > > > > > 
> > > > > > On Tue, 28 Apr 2009 15:41:08 -0400
> > > > > > Andres Salomon <dilinger@queued.net> wrote:
> > > > > > 
> > > > > > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > 
> > > > > > [...]
> > > > > > > > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I noticed that your name was on the ALC272
> > > > > > > > > > > > > > > support patch for ALSA intel-hda.  This
> > > > > > > > > > > > > > > patch basically sets ALC272 to use
> > > > > > > > > > > > > > > (mostly) the same code as ALC662.  I have
> > > > > > > > > > > > > > > two machines that have ALC272, and both
> > > > > > > > > > > > > > > of them need verb tables in order to
> > > > > > > > > > > > > > > function.  I'm wondering if ALC662 should
> > > > > > > > > > > > > > > really be used..
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Here's one -
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > This isn't the final version of the patch
> > > > > > > > > > > > > > > (there are further commits I made in
> > > > > > > > > > > > > > > order to support headphone mic stuff),
> > > > > > > > > > > > > > > but it gives you an idea of the codec
> > > > > > > > > > > > > > > values. The other is:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > All of these leave me wonder if there's a
> > > > > > > > > > > > > > > specific patch_alc272 function that could
> > > > > > > > > > > > > > > be written to rid ourselves of these
> > > > > > > > > > > > > > > specific quirks.  Are there machines with
> > > > > > > > > > > > > > > ALC272 that are functional with the
> > > > > > > > > > > > > > > current ALSA code?
> > > > > > > > > > > > > > 
> > > > > > [...]
> > > > > > > > 
> > > > > > > > Could you try sound-unstable tree a bit later again?
> > > > > > > > I found a bug in my patch, and fixed and updated GIT
> > > > > > > > tree now. At least, the headphone plugging should work
> > > > > > > > now.
> > > > > > > > 
> > > > > > > > The mic auto-detection still doesn't work with
> > > > > > > > model=auto, though. So, I'm going to take your patch
> > > > > > > > anyway later.  But I just wanted to be sure that the
> > > > > > > > current tree could work somehow better...
> > > > > > > > 
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I just updated and tried the current tree; still no
> > > > > > > sound/headphone output.  :(
> > > > > > 
> > > > > > 
> > > > > > Ok, I believe I've made some progress on this.  The problem
> > > > > > appears to be related to the autoconfig handling of the line
> > > > > > out nids.  The current code ends up with something like the
> > > > > > following:
> > > > > > 
> > > > > > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig: line_outs=1
> > > > > > (0x17/0x0/0x0/0x0/0x0)
> > > > > > ALSA sound/pci/hda/hda_codec.c:3837:    speaker_outs=0
> > > > > > (0x0/0x0/0x0/0x0/0x0)
> > > > > > ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1
> > > > > > (0x21/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:3842:
> > > > > > mono: mono_out=0x0 ALSA sound/pci/hda/hda_codec.c:3853:
> > > > > > inputs: mic=0x18, fmic=0x19, line=0x0, fline=0x0, cd=0x0,
> > > > > > aux=0x0
> > > > > > 
> > > > > > However, NID 0x17 is actually a speaker_out.  The code that
> > > > > > checks for line_outs in snd_hda_parse_pin_def_config()
> > > > > > unsets the speaker_out and uses that NID for a line_out.
> > > > > > For whatever reason, this breaks things (no sound output,
> > > > > > no headphone out).
> > > > > 
> > > > > That's intentional, and the driver checks that case, too.
> > > > > Please check the latest sound git tree and see the kernel
> > > > > message. You should have messages like "realtek: ..."
> > > > > 
> > > > > 
> > > > > Takashi
> > > > 
> > > > 
> > > > The realtek: lines don't appear to affect NID 0x17 at all.
> > > > Instead, they say:
> > > > 
> > > > ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No valid SSID,
> > > > checking pincfg 0x40178e2d for NID 0x1d ALSA
> > > > sound/pci/hda/patch_realtek.c:1170: realtek: Enabling init
> > > > ASM_ID=0x8e2d CODEC_ID=10ec0272 ALSA
> > > > sound/pci/hda/patch_realtek.c:1111: realtek: Enable HP
> > > > auto-muting on NID 0x21
> > > 
> > > Then 0x17 should be toggled when the jack on 0x21 is detected.
> > > 
> > > 
> > > Takashi
> > 
> > But since I get absolutely no sound through headphones or speakers,
> > I can't tell if it's being toggled.  :)
> 
> You can see the 0x17 in the codec proc whether it's changed at plugged
> / unplugged.  The driver should change its pin control dynamically.
> 
> > I've noticed:
> >  - in order to get speaker output, 0x17 *must* be defined as the
> > speaker-out, and 0x14 *must* be listed as a line-out pin.
> >  - in order to get headphone output, neither 0x17 nor 0x15 are to be
> > listed as the first line-out pin
> 
> Then it implies that 0x17 has nothing to do with the speaker, i.e. a
> BIOS bug.  0x14 could be the speaker output while 0x17 is just a
> dummy.
> 
>

Specifying 0x14 as the speaker-pin doesn't work, either.

Re: realtek ALC272 support

[Takashi Iwai]

At Thu, 30 Apr 2009 09:51:27 -0400,
Andres Salomon wrote:
> 
> On Thu, 30 Apr 2009 07:34:02 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Wed, 29 Apr 2009 13:01:42 -0400,
> > Andres Salomon wrote:
> > > 
> > > On Wed, 29 Apr 2009 15:09:20 +0200
> > > Takashi Iwai <tiwai@suse.de> wrote:
> > > 
> > > > At Wed, 29 Apr 2009 09:02:41 -0400,
> > > > Andres Salomon wrote:
> > > > > 
> > > > > On Wed, 29 Apr 2009 08:33:28 +0200
> > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > 
> > > > > > At Tue, 28 Apr 2009 18:21:55 -0400,
> > > > > > Andres Salomon wrote:
> > > > > > > 
> > > > > > > On Tue, 28 Apr 2009 15:41:08 -0400
> > > > > > > Andres Salomon <dilinger@queued.net> wrote:
> > > > > > > 
> > > > > > > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > 
> > > > > > > [...]
> > > > > > > > > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I noticed that your name was on the ALC272
> > > > > > > > > > > > > > > > support patch for ALSA intel-hda.  This
> > > > > > > > > > > > > > > > patch basically sets ALC272 to use
> > > > > > > > > > > > > > > > (mostly) the same code as ALC662.  I have
> > > > > > > > > > > > > > > > two machines that have ALC272, and both
> > > > > > > > > > > > > > > > of them need verb tables in order to
> > > > > > > > > > > > > > > > function.  I'm wondering if ALC662 should
> > > > > > > > > > > > > > > > really be used..
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Here's one -
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > This isn't the final version of the patch
> > > > > > > > > > > > > > > > (there are further commits I made in
> > > > > > > > > > > > > > > > order to support headphone mic stuff),
> > > > > > > > > > > > > > > > but it gives you an idea of the codec
> > > > > > > > > > > > > > > > values. The other is:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > All of these leave me wonder if there's a
> > > > > > > > > > > > > > > > specific patch_alc272 function that could
> > > > > > > > > > > > > > > > be written to rid ourselves of these
> > > > > > > > > > > > > > > > specific quirks.  Are there machines with
> > > > > > > > > > > > > > > > ALC272 that are functional with the
> > > > > > > > > > > > > > > > current ALSA code?
> > > > > > > > > > > > > > > 
> > > > > > > [...]
> > > > > > > > > 
> > > > > > > > > Could you try sound-unstable tree a bit later again?
> > > > > > > > > I found a bug in my patch, and fixed and updated GIT
> > > > > > > > > tree now. At least, the headphone plugging should work
> > > > > > > > > now.
> > > > > > > > > 
> > > > > > > > > The mic auto-detection still doesn't work with
> > > > > > > > > model=auto, though. So, I'm going to take your patch
> > > > > > > > > anyway later.  But I just wanted to be sure that the
> > > > > > > > > current tree could work somehow better...
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I just updated and tried the current tree; still no
> > > > > > > > sound/headphone output.  :(
> > > > > > > 
> > > > > > > 
> > > > > > > Ok, I believe I've made some progress on this.  The problem
> > > > > > > appears to be related to the autoconfig handling of the line
> > > > > > > out nids.  The current code ends up with something like the
> > > > > > > following:
> > > > > > > 
> > > > > > > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig: line_outs=1
> > > > > > > (0x17/0x0/0x0/0x0/0x0)
> > > > > > > ALSA sound/pci/hda/hda_codec.c:3837:    speaker_outs=0
> > > > > > > (0x0/0x0/0x0/0x0/0x0)
> > > > > > > ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1
> > > > > > > (0x21/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:3842:
> > > > > > > mono: mono_out=0x0 ALSA sound/pci/hda/hda_codec.c:3853:
> > > > > > > inputs: mic=0x18, fmic=0x19, line=0x0, fline=0x0, cd=0x0,
> > > > > > > aux=0x0
> > > > > > > 
> > > > > > > However, NID 0x17 is actually a speaker_out.  The code that
> > > > > > > checks for line_outs in snd_hda_parse_pin_def_config()
> > > > > > > unsets the speaker_out and uses that NID for a line_out.
> > > > > > > For whatever reason, this breaks things (no sound output,
> > > > > > > no headphone out).
> > > > > > 
> > > > > > That's intentional, and the driver checks that case, too.
> > > > > > Please check the latest sound git tree and see the kernel
> > > > > > message. You should have messages like "realtek: ..."
> > > > > > 
> > > > > > 
> > > > > > Takashi
> > > > > 
> > > > > 
> > > > > The realtek: lines don't appear to affect NID 0x17 at all.
> > > > > Instead, they say:
> > > > > 
> > > > > ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No valid SSID,
> > > > > checking pincfg 0x40178e2d for NID 0x1d ALSA
> > > > > sound/pci/hda/patch_realtek.c:1170: realtek: Enabling init
> > > > > ASM_ID=0x8e2d CODEC_ID=10ec0272 ALSA
> > > > > sound/pci/hda/patch_realtek.c:1111: realtek: Enable HP
> > > > > auto-muting on NID 0x21
> > > > 
> > > > Then 0x17 should be toggled when the jack on 0x21 is detected.
> > > > 
> > > > 
> > > > Takashi
> > > 
> > > But since I get absolutely no sound through headphones or speakers,
> > > I can't tell if it's being toggled.  :)
> > 
> > You can see the 0x17 in the codec proc whether it's changed at plugged
> > / unplugged.  The driver should change its pin control dynamically.
> > 
> > > I've noticed:
> > >  - in order to get speaker output, 0x17 *must* be defined as the
> > > speaker-out, and 0x14 *must* be listed as a line-out pin.
> > >  - in order to get headphone output, neither 0x17 nor 0x15 are to be
> > > listed as the first line-out pin
> > 
> > Then it implies that 0x17 has nothing to do with the speaker, i.e. a
> > BIOS bug.  0x14 could be the speaker output while 0x17 is just a
> > dummy.
> > 
> >
> 
> Specifying 0x14 as the speaker-pin doesn't work, either.

How did you test it?


Takashi

Re: realtek ALC272 support

[Andres Salomon]

On Mon, 04 May 2009 09:02:50 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Thu, 30 Apr 2009 09:51:27 -0400,
> Andres Salomon wrote:
> > 
> > On Thu, 30 Apr 2009 07:34:02 +0200
> > Takashi Iwai <tiwai@suse.de> wrote:
> > 
> > > At Wed, 29 Apr 2009 13:01:42 -0400,
> > > Andres Salomon wrote:
> > > > 
> > > > On Wed, 29 Apr 2009 15:09:20 +0200
> > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > 
> > > > > At Wed, 29 Apr 2009 09:02:41 -0400,
> > > > > Andres Salomon wrote:
> > > > > > 
> > > > > > On Wed, 29 Apr 2009 08:33:28 +0200
> > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > 
> > > > > > > At Tue, 28 Apr 2009 18:21:55 -0400,
> > > > > > > Andres Salomon wrote:
> > > > > > > > 
> > > > > > > > On Tue, 28 Apr 2009 15:41:08 -0400
> > > > > > > > Andres Salomon <dilinger@queued.net> wrote:
> > > > > > > > 
> > > > > > > > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > > 
> > > > > > > > [...]
> > > > > > > > > > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I noticed that your name was on the
> > > > > > > > > > > > > > > > > ALC272 support patch for ALSA
> > > > > > > > > > > > > > > > > intel-hda.  This patch basically sets
> > > > > > > > > > > > > > > > > ALC272 to use (mostly) the same code
> > > > > > > > > > > > > > > > > as ALC662.  I have two machines that
> > > > > > > > > > > > > > > > > have ALC272, and both of them need
> > > > > > > > > > > > > > > > > verb tables in order to function.
> > > > > > > > > > > > > > > > > I'm wondering if ALC662 should really
> > > > > > > > > > > > > > > > > be used..
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Here's one -
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > This isn't the final version of the
> > > > > > > > > > > > > > > > > patch (there are further commits I
> > > > > > > > > > > > > > > > > made in order to support headphone
> > > > > > > > > > > > > > > > > mic stuff), but it gives you an idea
> > > > > > > > > > > > > > > > > of the codec values. The other is:
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > All of these leave me wonder if
> > > > > > > > > > > > > > > > > there's a specific patch_alc272
> > > > > > > > > > > > > > > > > function that could be written to rid
> > > > > > > > > > > > > > > > > ourselves of these specific quirks.
> > > > > > > > > > > > > > > > > Are there machines with ALC272 that
> > > > > > > > > > > > > > > > > are functional with the current ALSA
> > > > > > > > > > > > > > > > > code?
> > > > > > > > > > > > > > > > 
> > > > > > > > [...]
> > > > > > > > > > 
> > > > > > > > > > Could you try sound-unstable tree a bit later again?
> > > > > > > > > > I found a bug in my patch, and fixed and updated GIT
> > > > > > > > > > tree now. At least, the headphone plugging should
> > > > > > > > > > work now.
> > > > > > > > > > 
> > > > > > > > > > The mic auto-detection still doesn't work with
> > > > > > > > > > model=auto, though. So, I'm going to take your patch
> > > > > > > > > > anyway later.  But I just wanted to be sure that the
> > > > > > > > > > current tree could work somehow better...
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > I just updated and tried the current tree; still no
> > > > > > > > > sound/headphone output.  :(
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Ok, I believe I've made some progress on this.  The
> > > > > > > > problem appears to be related to the autoconfig
> > > > > > > > handling of the line out nids.  The current code ends
> > > > > > > > up with something like the following:
> > > > > > > > 
> > > > > > > > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig:
> > > > > > > > line_outs=1 (0x17/0x0/0x0/0x0/0x0)
> > > > > > > > ALSA sound/pci/hda/hda_codec.c:3837:    speaker_outs=0
> > > > > > > > (0x0/0x0/0x0/0x0/0x0)
> > > > > > > > ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1
> > > > > > > > (0x21/0x0/0x0/0x0/0x0) ALSA
> > > > > > > > sound/pci/hda/hda_codec.c:3842: mono: mono_out=0x0 ALSA
> > > > > > > > sound/pci/hda/hda_codec.c:3853: inputs: mic=0x18,
> > > > > > > > fmic=0x19, line=0x0, fline=0x0, cd=0x0, aux=0x0
> > > > > > > > 
> > > > > > > > However, NID 0x17 is actually a speaker_out.  The code
> > > > > > > > that checks for line_outs in
> > > > > > > > snd_hda_parse_pin_def_config() unsets the speaker_out
> > > > > > > > and uses that NID for a line_out. For whatever reason,
> > > > > > > > this breaks things (no sound output, no headphone out).
> > > > > > > 
> > > > > > > That's intentional, and the driver checks that case, too.
> > > > > > > Please check the latest sound git tree and see the kernel
> > > > > > > message. You should have messages like "realtek: ..."
> > > > > > > 
> > > > > > > 
> > > > > > > Takashi
> > > > > > 
> > > > > > 
> > > > > > The realtek: lines don't appear to affect NID 0x17 at all.
> > > > > > Instead, they say:
> > > > > > 
> > > > > > ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No valid
> > > > > > SSID, checking pincfg 0x40178e2d for NID 0x1d ALSA
> > > > > > sound/pci/hda/patch_realtek.c:1170: realtek: Enabling init
> > > > > > ASM_ID=0x8e2d CODEC_ID=10ec0272 ALSA
> > > > > > sound/pci/hda/patch_realtek.c:1111: realtek: Enable HP
> > > > > > auto-muting on NID 0x21
> > > > > 
> > > > > Then 0x17 should be toggled when the jack on 0x21 is detected.
> > > > > 
> > > > > 
> > > > > Takashi
> > > > 
> > > > But since I get absolutely no sound through headphones or
> > > > speakers, I can't tell if it's being toggled.  :)
> > > 
> > > You can see the 0x17 in the codec proc whether it's changed at
> > > plugged / unplugged.  The driver should change its pin control
> > > dynamically.
> > > 
> > > > I've noticed:
> > > >  - in order to get speaker output, 0x17 *must* be defined as the
> > > > speaker-out, and 0x14 *must* be listed as a line-out pin.
> > > >  - in order to get headphone output, neither 0x17 nor 0x15 are
> > > > to be listed as the first line-out pin
> > > 
> > > Then it implies that 0x17 has nothing to do with the speaker,
> > > i.e. a BIOS bug.  0x14 could be the speaker output while 0x17 is
> > > just a dummy.
> > > 
> > >
> > 
> > Specifying 0x14 as the speaker-pin doesn't work, either.
> 
> How did you test it?
> 
> 
> Takashi

I had tried manually setting the speaker and line-out pins in the
autoconfig function.

Re: realtek ALC272 support

[Takashi Iwai]

At Mon, 4 May 2009 08:37:10 -0400,
Andres Salomon wrote:
> 
> On Mon, 04 May 2009 09:02:50 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Thu, 30 Apr 2009 09:51:27 -0400,
> > Andres Salomon wrote:
> > > 
> > > On Thu, 30 Apr 2009 07:34:02 +0200
> > > Takashi Iwai <tiwai@suse.de> wrote:
> > > 
> > > > At Wed, 29 Apr 2009 13:01:42 -0400,
> > > > Andres Salomon wrote:
> > > > > 
> > > > > On Wed, 29 Apr 2009 15:09:20 +0200
> > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > 
> > > > > > At Wed, 29 Apr 2009 09:02:41 -0400,
> > > > > > Andres Salomon wrote:
> > > > > > > 
> > > > > > > On Wed, 29 Apr 2009 08:33:28 +0200
> > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > 
> > > > > > > > At Tue, 28 Apr 2009 18:21:55 -0400,
> > > > > > > > Andres Salomon wrote:
> > > > > > > > > 
> > > > > > > > > On Tue, 28 Apr 2009 15:41:08 -0400
> > > > > > > > > Andres Salomon <dilinger@queued.net> wrote:
> > > > > > > > > 
> > > > > > > > > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > > > 
> > > > > > > > > [...]
> > > > > > > > > > > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > I noticed that your name was on the
> > > > > > > > > > > > > > > > > > ALC272 support patch for ALSA
> > > > > > > > > > > > > > > > > > intel-hda.  This patch basically sets
> > > > > > > > > > > > > > > > > > ALC272 to use (mostly) the same code
> > > > > > > > > > > > > > > > > > as ALC662.  I have two machines that
> > > > > > > > > > > > > > > > > > have ALC272, and both of them need
> > > > > > > > > > > > > > > > > > verb tables in order to function.
> > > > > > > > > > > > > > > > > > I'm wondering if ALC662 should really
> > > > > > > > > > > > > > > > > > be used..
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Here's one -
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > This isn't the final version of the
> > > > > > > > > > > > > > > > > > patch (there are further commits I
> > > > > > > > > > > > > > > > > > made in order to support headphone
> > > > > > > > > > > > > > > > > > mic stuff), but it gives you an idea
> > > > > > > > > > > > > > > > > > of the codec values. The other is:
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > All of these leave me wonder if
> > > > > > > > > > > > > > > > > > there's a specific patch_alc272
> > > > > > > > > > > > > > > > > > function that could be written to rid
> > > > > > > > > > > > > > > > > > ourselves of these specific quirks.
> > > > > > > > > > > > > > > > > > Are there machines with ALC272 that
> > > > > > > > > > > > > > > > > > are functional with the current ALSA
> > > > > > > > > > > > > > > > > > code?
> > > > > > > > > > > > > > > > > 
> > > > > > > > > [...]
> > > > > > > > > > > 
> > > > > > > > > > > Could you try sound-unstable tree a bit later again?
> > > > > > > > > > > I found a bug in my patch, and fixed and updated GIT
> > > > > > > > > > > tree now. At least, the headphone plugging should
> > > > > > > > > > > work now.
> > > > > > > > > > > 
> > > > > > > > > > > The mic auto-detection still doesn't work with
> > > > > > > > > > > model=auto, though. So, I'm going to take your patch
> > > > > > > > > > > anyway later.  But I just wanted to be sure that the
> > > > > > > > > > > current tree could work somehow better...
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > I just updated and tried the current tree; still no
> > > > > > > > > > sound/headphone output.  :(
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Ok, I believe I've made some progress on this.  The
> > > > > > > > > problem appears to be related to the autoconfig
> > > > > > > > > handling of the line out nids.  The current code ends
> > > > > > > > > up with something like the following:
> > > > > > > > > 
> > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig:
> > > > > > > > > line_outs=1 (0x17/0x0/0x0/0x0/0x0)
> > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3837:    speaker_outs=0
> > > > > > > > > (0x0/0x0/0x0/0x0/0x0)
> > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1
> > > > > > > > > (0x21/0x0/0x0/0x0/0x0) ALSA
> > > > > > > > > sound/pci/hda/hda_codec.c:3842: mono: mono_out=0x0 ALSA
> > > > > > > > > sound/pci/hda/hda_codec.c:3853: inputs: mic=0x18,
> > > > > > > > > fmic=0x19, line=0x0, fline=0x0, cd=0x0, aux=0x0
> > > > > > > > > 
> > > > > > > > > However, NID 0x17 is actually a speaker_out.  The code
> > > > > > > > > that checks for line_outs in
> > > > > > > > > snd_hda_parse_pin_def_config() unsets the speaker_out
> > > > > > > > > and uses that NID for a line_out. For whatever reason,
> > > > > > > > > this breaks things (no sound output, no headphone out).
> > > > > > > > 
> > > > > > > > That's intentional, and the driver checks that case, too.
> > > > > > > > Please check the latest sound git tree and see the kernel
> > > > > > > > message. You should have messages like "realtek: ..."
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Takashi
> > > > > > > 
> > > > > > > 
> > > > > > > The realtek: lines don't appear to affect NID 0x17 at all.
> > > > > > > Instead, they say:
> > > > > > > 
> > > > > > > ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No valid
> > > > > > > SSID, checking pincfg 0x40178e2d for NID 0x1d ALSA
> > > > > > > sound/pci/hda/patch_realtek.c:1170: realtek: Enabling init
> > > > > > > ASM_ID=0x8e2d CODEC_ID=10ec0272 ALSA
> > > > > > > sound/pci/hda/patch_realtek.c:1111: realtek: Enable HP
> > > > > > > auto-muting on NID 0x21
> > > > > > 
> > > > > > Then 0x17 should be toggled when the jack on 0x21 is detected.
> > > > > > 
> > > > > > 
> > > > > > Takashi
> > > > > 
> > > > > But since I get absolutely no sound through headphones or
> > > > > speakers, I can't tell if it's being toggled.  :)
> > > > 
> > > > You can see the 0x17 in the codec proc whether it's changed at
> > > > plugged / unplugged.  The driver should change its pin control
> > > > dynamically.
> > > > 
> > > > > I've noticed:
> > > > >  - in order to get speaker output, 0x17 *must* be defined as the
> > > > > speaker-out, and 0x14 *must* be listed as a line-out pin.
> > > > >  - in order to get headphone output, neither 0x17 nor 0x15 are
> > > > > to be listed as the first line-out pin
> > > > 
> > > > Then it implies that 0x17 has nothing to do with the speaker,
> > > > i.e. a BIOS bug.  0x14 could be the speaker output while 0x17 is
> > > > just a dummy.
> > > > 
> > > >
> > > 
> > > Specifying 0x14 as the speaker-pin doesn't work, either.
> > 
> > How did you test it?
> > 
> > 
> > Takashi
> 
> I had tried manually setting the speaker and line-out pins in the
> autoconfig function.

So... how?


Takashi

Re: realtek ALC272 support

[Andres Salomon]

On Mon, 04 May 2009 14:40:45 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Mon, 4 May 2009 08:37:10 -0400,
> Andres Salomon wrote:
> > 
> > On Mon, 04 May 2009 09:02:50 +0200
> > Takashi Iwai <tiwai@suse.de> wrote:
> > 
> > > At Thu, 30 Apr 2009 09:51:27 -0400,
> > > Andres Salomon wrote:
> > > > 
> > > > On Thu, 30 Apr 2009 07:34:02 +0200
> > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > 
> > > > > At Wed, 29 Apr 2009 13:01:42 -0400,
> > > > > Andres Salomon wrote:
> > > > > > 
> > > > > > On Wed, 29 Apr 2009 15:09:20 +0200
> > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > 
> > > > > > > At Wed, 29 Apr 2009 09:02:41 -0400,
> > > > > > > Andres Salomon wrote:
> > > > > > > > 
> > > > > > > > On Wed, 29 Apr 2009 08:33:28 +0200
> > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > 
> > > > > > > > > At Tue, 28 Apr 2009 18:21:55 -0400,
> > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > 
> > > > > > > > > > On Tue, 28 Apr 2009 15:41:08 -0400
> > > > > > > > > > Andres Salomon <dilinger@queued.net> wrote:
> > > > > > > > > > 
> > > > > > > > > > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > > > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > > > > 
> > > > > > > > > > [...]
> > > > > > > > > > > > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > > > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > I noticed that your name was on
> > > > > > > > > > > > > > > > > > > the ALC272 support patch for ALSA
> > > > > > > > > > > > > > > > > > > intel-hda.  This patch basically
> > > > > > > > > > > > > > > > > > > sets ALC272 to use (mostly) the
> > > > > > > > > > > > > > > > > > > same code as ALC662.  I have two
> > > > > > > > > > > > > > > > > > > machines that have ALC272, and
> > > > > > > > > > > > > > > > > > > both of them need verb tables in
> > > > > > > > > > > > > > > > > > > order to function. I'm wondering
> > > > > > > > > > > > > > > > > > > if ALC662 should really be used..
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Here's one -
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > This isn't the final version of
> > > > > > > > > > > > > > > > > > > the patch (there are further
> > > > > > > > > > > > > > > > > > > commits I made in order to
> > > > > > > > > > > > > > > > > > > support headphone mic stuff), but
> > > > > > > > > > > > > > > > > > > it gives you an idea of the codec
> > > > > > > > > > > > > > > > > > > values. The other is:
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > All of these leave me wonder if
> > > > > > > > > > > > > > > > > > > there's a specific patch_alc272
> > > > > > > > > > > > > > > > > > > function that could be written to
> > > > > > > > > > > > > > > > > > > rid ourselves of these specific
> > > > > > > > > > > > > > > > > > > quirks. Are there machines with
> > > > > > > > > > > > > > > > > > > ALC272 that are functional with
> > > > > > > > > > > > > > > > > > > the current ALSA code?
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > [...]
> > > > > > > > > > > > 
> > > > > > > > > > > > Could you try sound-unstable tree a bit later
> > > > > > > > > > > > again? I found a bug in my patch, and fixed and
> > > > > > > > > > > > updated GIT tree now. At least, the headphone
> > > > > > > > > > > > plugging should work now.
> > > > > > > > > > > > 
> > > > > > > > > > > > The mic auto-detection still doesn't work with
> > > > > > > > > > > > model=auto, though. So, I'm going to take your
> > > > > > > > > > > > patch anyway later.  But I just wanted to be
> > > > > > > > > > > > sure that the current tree could work somehow
> > > > > > > > > > > > better...
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Hi,
> > > > > > > > > > > 
> > > > > > > > > > > I just updated and tried the current tree; still
> > > > > > > > > > > no sound/headphone output.  :(
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Ok, I believe I've made some progress on this.  The
> > > > > > > > > > problem appears to be related to the autoconfig
> > > > > > > > > > handling of the line out nids.  The current code
> > > > > > > > > > ends up with something like the following:
> > > > > > > > > > 
> > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig:
> > > > > > > > > > line_outs=1 (0x17/0x0/0x0/0x0/0x0)
> > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3837:
> > > > > > > > > > speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
> > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1
> > > > > > > > > > (0x21/0x0/0x0/0x0/0x0) ALSA
> > > > > > > > > > sound/pci/hda/hda_codec.c:3842: mono: mono_out=0x0
> > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3853: inputs:
> > > > > > > > > > mic=0x18, fmic=0x19, line=0x0, fline=0x0, cd=0x0,
> > > > > > > > > > aux=0x0
> > > > > > > > > > 
> > > > > > > > > > However, NID 0x17 is actually a speaker_out.  The
> > > > > > > > > > code that checks for line_outs in
> > > > > > > > > > snd_hda_parse_pin_def_config() unsets the
> > > > > > > > > > speaker_out and uses that NID for a line_out. For
> > > > > > > > > > whatever reason, this breaks things (no sound
> > > > > > > > > > output, no headphone out).
> > > > > > > > > 
> > > > > > > > > That's intentional, and the driver checks that case,
> > > > > > > > > too. Please check the latest sound git tree and see
> > > > > > > > > the kernel message. You should have messages like
> > > > > > > > > "realtek: ..."
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Takashi
> > > > > > > > 
> > > > > > > > 
> > > > > > > > The realtek: lines don't appear to affect NID 0x17 at
> > > > > > > > all. Instead, they say:
> > > > > > > > 
> > > > > > > > ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No
> > > > > > > > valid SSID, checking pincfg 0x40178e2d for NID 0x1d ALSA
> > > > > > > > sound/pci/hda/patch_realtek.c:1170: realtek: Enabling
> > > > > > > > init ASM_ID=0x8e2d CODEC_ID=10ec0272 ALSA
> > > > > > > > sound/pci/hda/patch_realtek.c:1111: realtek: Enable HP
> > > > > > > > auto-muting on NID 0x21
> > > > > > > 
> > > > > > > Then 0x17 should be toggled when the jack on 0x21 is
> > > > > > > detected.
> > > > > > > 
> > > > > > > 
> > > > > > > Takashi
> > > > > > 
> > > > > > But since I get absolutely no sound through headphones or
> > > > > > speakers, I can't tell if it's being toggled.  :)
> > > > > 
> > > > > You can see the 0x17 in the codec proc whether it's changed at
> > > > > plugged / unplugged.  The driver should change its pin control
> > > > > dynamically.
> > > > > 
> > > > > > I've noticed:
> > > > > >  - in order to get speaker output, 0x17 *must* be defined
> > > > > > as the speaker-out, and 0x14 *must* be listed as a line-out
> > > > > > pin.
> > > > > >  - in order to get headphone output, neither 0x17 nor 0x15
> > > > > > are to be listed as the first line-out pin
> > > > > 
> > > > > Then it implies that 0x17 has nothing to do with the speaker,
> > > > > i.e. a BIOS bug.  0x14 could be the speaker output while 0x17
> > > > > is just a dummy.
> > > > > 
> > > > >
> > > > 
> > > > Specifying 0x14 as the speaker-pin doesn't work, either.
> > > 
> > > How did you test it?
> > > 
> > > 
> > > Takashi
> > 
> > I had tried manually setting the speaker and line-out pins in the
> > autoconfig function.
> 
> So... how?
> 
> 
> Takashi


Basically, several variations of:

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index b91f6ed..ed98262 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -3786,6 +3786,11 @@ int snd_hda_parse_pin_def_config(struct hda_codec *codec,
                cfg->input_pins[AUTO_PIN_FRONT_LINE] = 0;
        }
 
+       cfg->speaker_pins[0] = 0x14;
+       cfg->speaker_outs = 1;
+       cfg->line_outs = 1;
+       cfg->line_out_pins[0] = 0x14;
+
        /*
         * FIX-UP: if no line-outs are detected, try to use speaker or HP pin
         * as a primary output


Following by playing speaker-test and checking for speaker and/or
headphone output.

Re: realtek ALC272 support

[Takashi Iwai]

At Mon, 4 May 2009 10:03:08 -0400,
Andres Salomon wrote:
> 
> On Mon, 04 May 2009 14:40:45 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Mon, 4 May 2009 08:37:10 -0400,
> > Andres Salomon wrote:
> > > 
> > > On Mon, 04 May 2009 09:02:50 +0200
> > > Takashi Iwai <tiwai@suse.de> wrote:
> > > 
> > > > At Thu, 30 Apr 2009 09:51:27 -0400,
> > > > Andres Salomon wrote:
> > > > > 
> > > > > On Thu, 30 Apr 2009 07:34:02 +0200
> > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > 
> > > > > > At Wed, 29 Apr 2009 13:01:42 -0400,
> > > > > > Andres Salomon wrote:
> > > > > > > 
> > > > > > > On Wed, 29 Apr 2009 15:09:20 +0200
> > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > 
> > > > > > > > At Wed, 29 Apr 2009 09:02:41 -0400,
> > > > > > > > Andres Salomon wrote:
> > > > > > > > > 
> > > > > > > > > On Wed, 29 Apr 2009 08:33:28 +0200
> > > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > > 
> > > > > > > > > > At Tue, 28 Apr 2009 18:21:55 -0400,
> > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > 
> > > > > > > > > > > On Tue, 28 Apr 2009 15:41:08 -0400
> > > > > > > > > > > Andres Salomon <dilinger@queued.net> wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > > > > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > [...]
> > > > > > > > > > > > > > > > > > > At Fri, 24 Apr 2009 15:24:15 -0400,
> > > > > > > > > > > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > I noticed that your name was on
> > > > > > > > > > > > > > > > > > > > the ALC272 support patch for ALSA
> > > > > > > > > > > > > > > > > > > > intel-hda.  This patch basically
> > > > > > > > > > > > > > > > > > > > sets ALC272 to use (mostly) the
> > > > > > > > > > > > > > > > > > > > same code as ALC662.  I have two
> > > > > > > > > > > > > > > > > > > > machines that have ALC272, and
> > > > > > > > > > > > > > > > > > > > both of them need verb tables in
> > > > > > > > > > > > > > > > > > > > order to function. I'm wondering
> > > > > > > > > > > > > > > > > > > > if ALC662 should really be used..
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Here's one -
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > This isn't the final version of
> > > > > > > > > > > > > > > > > > > > the patch (there are further
> > > > > > > > > > > > > > > > > > > > commits I made in order to
> > > > > > > > > > > > > > > > > > > > support headphone mic stuff), but
> > > > > > > > > > > > > > > > > > > > it gives you an idea of the codec
> > > > > > > > > > > > > > > > > > > > values. The other is:
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > All of these leave me wonder if
> > > > > > > > > > > > > > > > > > > > there's a specific patch_alc272
> > > > > > > > > > > > > > > > > > > > function that could be written to
> > > > > > > > > > > > > > > > > > > > rid ourselves of these specific
> > > > > > > > > > > > > > > > > > > > quirks. Are there machines with
> > > > > > > > > > > > > > > > > > > > ALC272 that are functional with
> > > > > > > > > > > > > > > > > > > > the current ALSA code?
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > [...]
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Could you try sound-unstable tree a bit later
> > > > > > > > > > > > > again? I found a bug in my patch, and fixed and
> > > > > > > > > > > > > updated GIT tree now. At least, the headphone
> > > > > > > > > > > > > plugging should work now.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > The mic auto-detection still doesn't work with
> > > > > > > > > > > > > model=auto, though. So, I'm going to take your
> > > > > > > > > > > > > patch anyway later.  But I just wanted to be
> > > > > > > > > > > > > sure that the current tree could work somehow
> > > > > > > > > > > > > better...
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > > I just updated and tried the current tree; still
> > > > > > > > > > > > no sound/headphone output.  :(
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Ok, I believe I've made some progress on this.  The
> > > > > > > > > > > problem appears to be related to the autoconfig
> > > > > > > > > > > handling of the line out nids.  The current code
> > > > > > > > > > > ends up with something like the following:
> > > > > > > > > > > 
> > > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig:
> > > > > > > > > > > line_outs=1 (0x17/0x0/0x0/0x0/0x0)
> > > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3837:
> > > > > > > > > > > speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
> > > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3841:    hp_outs=1
> > > > > > > > > > > (0x21/0x0/0x0/0x0/0x0) ALSA
> > > > > > > > > > > sound/pci/hda/hda_codec.c:3842: mono: mono_out=0x0
> > > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3853: inputs:
> > > > > > > > > > > mic=0x18, fmic=0x19, line=0x0, fline=0x0, cd=0x0,
> > > > > > > > > > > aux=0x0
> > > > > > > > > > > 
> > > > > > > > > > > However, NID 0x17 is actually a speaker_out.  The
> > > > > > > > > > > code that checks for line_outs in
> > > > > > > > > > > snd_hda_parse_pin_def_config() unsets the
> > > > > > > > > > > speaker_out and uses that NID for a line_out. For
> > > > > > > > > > > whatever reason, this breaks things (no sound
> > > > > > > > > > > output, no headphone out).
> > > > > > > > > > 
> > > > > > > > > > That's intentional, and the driver checks that case,
> > > > > > > > > > too. Please check the latest sound git tree and see
> > > > > > > > > > the kernel message. You should have messages like
> > > > > > > > > > "realtek: ..."
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Takashi
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > The realtek: lines don't appear to affect NID 0x17 at
> > > > > > > > > all. Instead, they say:
> > > > > > > > > 
> > > > > > > > > ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No
> > > > > > > > > valid SSID, checking pincfg 0x40178e2d for NID 0x1d ALSA
> > > > > > > > > sound/pci/hda/patch_realtek.c:1170: realtek: Enabling
> > > > > > > > > init ASM_ID=0x8e2d CODEC_ID=10ec0272 ALSA
> > > > > > > > > sound/pci/hda/patch_realtek.c:1111: realtek: Enable HP
> > > > > > > > > auto-muting on NID 0x21
> > > > > > > > 
> > > > > > > > Then 0x17 should be toggled when the jack on 0x21 is
> > > > > > > > detected.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Takashi
> > > > > > > 
> > > > > > > But since I get absolutely no sound through headphones or
> > > > > > > speakers, I can't tell if it's being toggled.  :)
> > > > > > 
> > > > > > You can see the 0x17 in the codec proc whether it's changed at
> > > > > > plugged / unplugged.  The driver should change its pin control
> > > > > > dynamically.
> > > > > > 
> > > > > > > I've noticed:
> > > > > > >  - in order to get speaker output, 0x17 *must* be defined
> > > > > > > as the speaker-out, and 0x14 *must* be listed as a line-out
> > > > > > > pin.
> > > > > > >  - in order to get headphone output, neither 0x17 nor 0x15
> > > > > > > are to be listed as the first line-out pin
> > > > > > 
> > > > > > Then it implies that 0x17 has nothing to do with the speaker,
> > > > > > i.e. a BIOS bug.  0x14 could be the speaker output while 0x17
> > > > > > is just a dummy.
> > > > > > 
> > > > > >
> > > > > 
> > > > > Specifying 0x14 as the speaker-pin doesn't work, either.
> > > > 
> > > > How did you test it?
> > > > 
> > > > 
> > > > Takashi
> > > 
> > > I had tried manually setting the speaker and line-out pins in the
> > > autoconfig function.
> > 
> > So... how?
> > 
> > 
> > Takashi
> 
> 
> Basically, several variations of:

Well, that's basically a bad place to modify.

You can change the pin config and reconfigure the driver dynamically
via sysfs interface.  (Better use it on 2.6.30, though.)
See Documentation/sound/alsa/HD-Audio.txt.


Takashi

> 
> diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> index b91f6ed..ed98262 100644
> --- a/sound/pci/hda/hda_codec.c
> +++ b/sound/pci/hda/hda_codec.c
> @@ -3786,6 +3786,11 @@ int snd_hda_parse_pin_def_config(struct hda_codec *codec,
>                 cfg->input_pins[AUTO_PIN_FRONT_LINE] = 0;
>         }
>  
> +       cfg->speaker_pins[0] = 0x14;
> +       cfg->speaker_outs = 1;
> +       cfg->line_outs = 1;
> +       cfg->line_out_pins[0] = 0x14;
> +
>         /*
>          * FIX-UP: if no line-outs are detected, try to use speaker or HP pin
>          * as a primary output
> 
> 
> Following by playing speaker-test and checking for speaker and/or
> headphone output.
> 

Re: realtek ALC272 support

[Andres Salomon]

On Mon, 04 May 2009 16:18:13 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Mon, 4 May 2009 10:03:08 -0400,
> Andres Salomon wrote:
> > 
> > On Mon, 04 May 2009 14:40:45 +0200
> > Takashi Iwai <tiwai@suse.de> wrote:
> > 
> > > At Mon, 4 May 2009 08:37:10 -0400,
> > > Andres Salomon wrote:
> > > > 
> > > > On Mon, 04 May 2009 09:02:50 +0200
> > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > 
> > > > > At Thu, 30 Apr 2009 09:51:27 -0400,
> > > > > Andres Salomon wrote:
> > > > > > 
> > > > > > On Thu, 30 Apr 2009 07:34:02 +0200
> > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > 
> > > > > > > At Wed, 29 Apr 2009 13:01:42 -0400,
> > > > > > > Andres Salomon wrote:
> > > > > > > > 
> > > > > > > > On Wed, 29 Apr 2009 15:09:20 +0200
> > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > 
> > > > > > > > > At Wed, 29 Apr 2009 09:02:41 -0400,
> > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > 
> > > > > > > > > > On Wed, 29 Apr 2009 08:33:28 +0200
> > > > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > > > 
> > > > > > > > > > > At Tue, 28 Apr 2009 18:21:55 -0400,
> > > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > On Tue, 28 Apr 2009 15:41:08 -0400
> > > > > > > > > > > > Andres Salomon <dilinger@queued.net> wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > > > > > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > [...]
> > > > > > > > > > > > > > > > > > > > At Fri, 24 Apr 2009 15:24:15
> > > > > > > > > > > > > > > > > > > > -0400, Andres Salomon wrote:
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > I noticed that your name was
> > > > > > > > > > > > > > > > > > > > > on the ALC272 support patch
> > > > > > > > > > > > > > > > > > > > > for ALSA intel-hda.  This
> > > > > > > > > > > > > > > > > > > > > patch basically sets ALC272
> > > > > > > > > > > > > > > > > > > > > to use (mostly) the same code
> > > > > > > > > > > > > > > > > > > > > as ALC662.  I have two
> > > > > > > > > > > > > > > > > > > > > machines that have ALC272,
> > > > > > > > > > > > > > > > > > > > > and both of them need verb
> > > > > > > > > > > > > > > > > > > > > tables in order to function.
> > > > > > > > > > > > > > > > > > > > > I'm wondering if ALC662
> > > > > > > > > > > > > > > > > > > > > should really be used..
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Here's one -
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > This isn't the final version
> > > > > > > > > > > > > > > > > > > > > of the patch (there are
> > > > > > > > > > > > > > > > > > > > > further commits I made in
> > > > > > > > > > > > > > > > > > > > > order to support headphone
> > > > > > > > > > > > > > > > > > > > > mic stuff), but it gives you
> > > > > > > > > > > > > > > > > > > > > an idea of the codec values.
> > > > > > > > > > > > > > > > > > > > > The other is:
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > All of these leave me wonder
> > > > > > > > > > > > > > > > > > > > > if there's a specific
> > > > > > > > > > > > > > > > > > > > > patch_alc272 function that
> > > > > > > > > > > > > > > > > > > > > could be written to rid
> > > > > > > > > > > > > > > > > > > > > ourselves of these specific
> > > > > > > > > > > > > > > > > > > > > quirks. Are there machines
> > > > > > > > > > > > > > > > > > > > > with ALC272 that are
> > > > > > > > > > > > > > > > > > > > > functional with the current
> > > > > > > > > > > > > > > > > > > > > ALSA code?
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > [...]
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Could you try sound-unstable tree a bit
> > > > > > > > > > > > > > later again? I found a bug in my patch, and
> > > > > > > > > > > > > > fixed and updated GIT tree now. At least,
> > > > > > > > > > > > > > the headphone plugging should work now.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The mic auto-detection still doesn't work
> > > > > > > > > > > > > > with model=auto, though. So, I'm going to
> > > > > > > > > > > > > > take your patch anyway later.  But I just
> > > > > > > > > > > > > > wanted to be sure that the current tree
> > > > > > > > > > > > > > could work somehow better...
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I just updated and tried the current tree;
> > > > > > > > > > > > > still no sound/headphone output.  :(
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Ok, I believe I've made some progress on this.
> > > > > > > > > > > > The problem appears to be related to the
> > > > > > > > > > > > autoconfig handling of the line out nids.  The
> > > > > > > > > > > > current code ends up with something like the
> > > > > > > > > > > > following:
> > > > > > > > > > > > 
> > > > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig:
> > > > > > > > > > > > line_outs=1 (0x17/0x0/0x0/0x0/0x0)
> > > > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3837:
> > > > > > > > > > > > speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
> > > > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3841:
> > > > > > > > > > > > hp_outs=1 (0x21/0x0/0x0/0x0/0x0) ALSA
> > > > > > > > > > > > sound/pci/hda/hda_codec.c:3842: mono:
> > > > > > > > > > > > mono_out=0x0 ALSA
> > > > > > > > > > > > sound/pci/hda/hda_codec.c:3853: inputs:
> > > > > > > > > > > > mic=0x18, fmic=0x19, line=0x0, fline=0x0,
> > > > > > > > > > > > cd=0x0, aux=0x0
> > > > > > > > > > > > 
> > > > > > > > > > > > However, NID 0x17 is actually a speaker_out.
> > > > > > > > > > > > The code that checks for line_outs in
> > > > > > > > > > > > snd_hda_parse_pin_def_config() unsets the
> > > > > > > > > > > > speaker_out and uses that NID for a line_out.
> > > > > > > > > > > > For whatever reason, this breaks things (no
> > > > > > > > > > > > sound output, no headphone out).
> > > > > > > > > > > 
> > > > > > > > > > > That's intentional, and the driver checks that
> > > > > > > > > > > case, too. Please check the latest sound git tree
> > > > > > > > > > > and see the kernel message. You should have
> > > > > > > > > > > messages like "realtek: ..."
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Takashi
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > The realtek: lines don't appear to affect NID 0x17
> > > > > > > > > > at all. Instead, they say:
> > > > > > > > > > 
> > > > > > > > > > ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No
> > > > > > > > > > valid SSID, checking pincfg 0x40178e2d for NID 0x1d
> > > > > > > > > > ALSA sound/pci/hda/patch_realtek.c:1170: realtek:
> > > > > > > > > > Enabling init ASM_ID=0x8e2d CODEC_ID=10ec0272 ALSA
> > > > > > > > > > sound/pci/hda/patch_realtek.c:1111: realtek: Enable
> > > > > > > > > > HP auto-muting on NID 0x21
> > > > > > > > > 
> > > > > > > > > Then 0x17 should be toggled when the jack on 0x21 is
> > > > > > > > > detected.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Takashi
> > > > > > > > 
> > > > > > > > But since I get absolutely no sound through headphones
> > > > > > > > or speakers, I can't tell if it's being toggled.  :)
> > > > > > > 
> > > > > > > You can see the 0x17 in the codec proc whether it's
> > > > > > > changed at plugged / unplugged.  The driver should change
> > > > > > > its pin control dynamically.
> > > > > > > 
> > > > > > > > I've noticed:
> > > > > > > >  - in order to get speaker output, 0x17 *must* be
> > > > > > > > defined as the speaker-out, and 0x14 *must* be listed
> > > > > > > > as a line-out pin.
> > > > > > > >  - in order to get headphone output, neither 0x17 nor
> > > > > > > > 0x15 are to be listed as the first line-out pin
> > > > > > > 
> > > > > > > Then it implies that 0x17 has nothing to do with the
> > > > > > > speaker, i.e. a BIOS bug.  0x14 could be the speaker
> > > > > > > output while 0x17 is just a dummy.
> > > > > > > 
> > > > > > >
> > > > > > 
> > > > > > Specifying 0x14 as the speaker-pin doesn't work, either.
> > > > > 
> > > > > How did you test it?
> > > > > 
> > > > > 
> > > > > Takashi
> > > > 
> > > > I had tried manually setting the speaker and line-out pins in
> > > > the autoconfig function.
> > > 
> > > So... how?
> > > 
> > > 
> > > Takashi
> > 
> > 
> > Basically, several variations of:
> 
> Well, that's basically a bad place to modify.
> 
> You can change the pin config and reconfigure the driver dynamically
> via sysfs interface.  (Better use it on 2.6.30, though.)
> See Documentation/sound/alsa/HD-Audio.txt.
> 
> 

Unfortunately, I can no longer test it, as I don't have access to the
hardware anymore.