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=76... > > > > > > > > > > > > > > > > > > > > > > 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=72... > > > > > > > > > > > > > > > > > > > > > > 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.