At Sun, 17 Feb 2013 23:23:16 +1030, Jonathan Woithe wrote:
On Sun, Feb 17, 2013 at 09:32:38AM +0100, Takashi Iwai wrote:
I've been able to test this (snapshot as of two days ago, reports version number 3.8.0-rc5+ via uname). As expected there have been some improvements.
Thanks for testing.
Things which work:
"Headphone Jack Mode" allows switching between "Headphone" and "Line out". Both of these mode settings appear to work.
There are separate "Headphone" and "Speaker" volume controls.
The "Headphone" volume control influences the headphone jack volume.
An "Auto-Mute Mode" control appears in alsamixer (it was missing on earlier versions).
Alsamixer recognises the presence of two ADCs, giving "Capture" and "Capture 1" controls, with corresponding "Input Source" controls.
Things which don't work or are missing:
- "Headphone Jack Mode" lacks options to enable various "mic" or "line in" modes (all of which are possible on this system)
Yes, it is still unimplemented. So, it's expected not to be there yet. If you can hack it by yourself, let me know.
I may be able to give this a go, but from what I recall there was some debate as to how this should be implemented. Has that been resolved yet?
No, we need to try to implement something and discuss later. I think simply implementing two things would work: providing the vref setup in Headphone Jack Mode enum, and add a pin to the Input Source. User would require two setups, but it's less conflicting with giving implicit dependency with each other, IMO.
Is there any code I could use as a template or example?
No template, since the parser code has been completely rewritten recently. Just take a look at hda_generic.c.
- The "Input source" controls don't offer the "headphone jack" as a possible source.
Ditto.
Ok.
- The built-in speaker is completely silent under all situations I have come up with. The setting of "Auto-Mute Mode" has no effect, neither does a manual unmute of the "Speaker" volume control. While I don't personally care much about this I suspect others might.
Hm, this is really mysterious. I have no idea which init code causes the problem, and it's hard to debug without a hardware. Could you try to figure out which setup is missing?
I spent a quite some time on this using hda-verb tonight with no success. I tried many combinations of mute settings and in the end unmuted every node I can see which lies between the DAC (nid 0x2) and the speaker in this laptop (nid 0x10). That is:
- Unmute the inputs on node 0x9
- Maximise the volume on node 0x9
- Unmute the input to node 0x10
Even with this the speakers remained mute. I then tried using the relevant parts of the S702X initialisation sequence from 3.3.5 but even this didn't permit the speaker to make any sound. Whatever's going on it's subtle.
I confirmed that the alsamixer "Speaker Volume" control manipulated the output volume control of node 0x9 as it should.
A quick comparison of /proc/asound/card0/codec#0 from 3.3.5 (where the speaker works) and 3.8.0-rc5+ (where it doesn't) failed to show anything obvious. A more detailed comparison may be required.
Hm, then maybe the default initialization verbs for ALC260 does something harmful for this machine? A quick (untested) patch is below.
As eluded to above, the "Auto-Mute Mode" control appears to do nothing.
There's no "Mic Jack Mode" control to control the mode of the "mic" jack. This jack supports line-in mode as well as the various "mic" modes which give varying bias voltages.
Strange, the jack mode should appear all input jacks except for the fixed pin. Could you give alsa-info.sh output with the latest code?
The alsa-info is included at the end of this message. To assist in the debugging of the speaker problem I've also included the output generated from 3.3.5. Both of these had the speaker unmuted and set to the same volume in alsamixer, and the 3.8.0-rc5+ one also had auto-mute mode disabled so they should be directly comparable.
To confirm the behaviour: the "Headphone Jack Mode" control appears in 3.8.0-rc5+ but a corresponding control for the mic/line-in jack does not.
Ah, I see. This doesn't appear as default. You need to pass a hint string in the firmware patch file. See a brief description in Documentation/sound/alsa/HD-Audio.txt.
Takashi