At Sun, 17 Feb 2013 18:00:21 +0100, Takashi Iwai wrote:
At Sun, 17 Feb 2013 17:59:29 +0100, Takashi Iwai wrote:
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.
Oops, forgot got attach.
Scratch that. It doesn't work as expected. Try the following one instead.
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 48c9d10..e0e0a5a 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -1516,8 +1516,14 @@ static void alc260_fixup_fsc_s7020(struct hda_codec *codec, { struct alc_spec *spec = codec->spec;
- if (action == HDA_FIXUP_ACT_PRE_PROBE) + switch (action) { + case HDA_FIXUP_ACT_PRE_PROBE: spec->gen.add_out_jack_modes = 1; + break; + case HDA_FIXUP_ACT_PROBE: + spec->init_amp = ALC_INIT_NONE; + break; + } }
static const struct hda_fixup alc260_fixups[] = {