At Sun, 13 Jan 2013 15:09:36 +1030, Jonathan Woithe wrote:
On Tue, Jan 08, 2013 at 03:48:57PM +0100, Takashi Iwai wrote:
Node 0x10 is notionally labelled "headphone pin" in the ALC260 datasheet.
You can forget the pin notion in the datasheet. It's just pin assignment Realtek thought as a standard arrangement.
Absolutely - that was abundantly clear when I first added the S7020 details years ago. The comment was only made in an attempt to make the comments in the original driver clearer to those reading them now.
I've just looked now. 3.3.5 was booted, alsamixer does not show any "automute" control to enable or disable this. In any case, automute is certainly not happening, so I'm guessing the answer to your question is no.
There is no automute behavior switching control in the 3.3.x kernel driver, so no wonder :)
I wasn't surprised since I thought this too. However, I was asked to test it so I did.
I took a look at your alsa-info.sh outputs now, but unfortunately I see no obvious problem there. At least, the path to the speaker looks sane: : And all GPIOs are cleared too.
Agreed. Given that the headphone jack works and the respective pin definition is very similar, I also can't see any obvious reason why things are getting messed up. Something subtle perhaps?
A possible cause I noticed later is the lack of the headphone amp on the speaker pin. This might be abused for controlling the speaker amp.
The differences are that the old driver cleared unused pins such as 0x0f, 0x11, 0x13 and 0x15. Could you try to set the pin ctl to 0 for these widgets via hda-verb on the fly?
I will try this, hopefully in the next few days. Like you I suspect, I can't see that this should make any difference to the speaker's ability to put out audio or to ALSA's ability to populate alsa-mixer correctly, but it's easy enough to eliminate it through testing.
Other than that, the headphone jack is set up with the HP amp and the mic is with VREF 50. They can be changed on the fly, too.
I'll run through some of these variations and let you know the result.
I noticed your big refactoring patch go past last week. Is there anything in there which I should test in relation to the ALC260 / Fujitsu issue we've been discussing, or should I await further info?
It's worth to test my latest code, yes. There are lots of fixes there, too, together with code refactoring.
You can test either master, test/hda-gen-parser or test/hda-migrate branch of sound-unstable tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
Or if you want to avoid the kernel rebuild, you can try alsa-driver externally from a snapshot tarball: ftp://ftp.suse.com/pub/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
thanks,
Takashi