Re: [alsa-devel] HDA regression on Fujitsu S7020 laptop (ALC260 codec)
Hi Takashi
On Wed, Feb 20, 2013 at 02:14:20PM +0100, Takashi Iwai wrote:
Sounds good - I will test in the next day or so and report back. What's the most efficient way to get hold of this tree / branch given that I have the for-next branch of sound.git? Can I somehow leverage this, or do I need to do a completely separate checkout? Apologies if this is a basic question - I'm still coming to terms with git.
sound-unstable git tree always contains the sound git tree master branch, so everything is there basically. ...
What's the next step in the process? I've reported the outcome of the tests of sound-unstable as per that report progress is being made. Is it a case of waiting for things to stabilise, or do you need me to do something to move things along? If so, what?
I merged the patches to the main sound git tree for-next branch now.
Also a few updates are merged there, too: now the hp mic jack mode should be able to change the pin control no matter whether which capture source is. Also, the capture source won't change the hp/mic pinctl when the jack mode enum is created. This reduces the automation but also reduces the confusion, too. After all, when jack mode is present, user wants to control the pin by himself.
Let me know if anything else is missing or broken.
I've given this new revision a quick test; sorry for the delay. With this revision, when using "model=fujitsu-jwse" things seem to be working pretty well. In particular, the updates you mention greatly improve usability; the lack of automatic interaction between mixer controls makes it much easier to use and understand.
I think everything is present and accounted for in this latest revision. Thanks for your work on this.
The only slightly odd thing I noticed was that whenever the driver is loaded the "headphone mic jack mode" defaults to "mic bias 80pc", rather than "line out" or "headphone" which I would have expected. Obviously this can be manually or automatically overridden after module load, but in many ways it would be good if it defaulted to one of the output modes (given that the jack's primary purpose is for output).
Where does this leave us now? Is the "fujitsu-jwse" a permanent thing, or will the respective changes be rolled into something more generic?
Regards jonathan
At Sun, 10 Mar 2013 15:28:54 +1030, Jonathan Woithe wrote:
Hi Takashi
On Wed, Feb 20, 2013 at 02:14:20PM +0100, Takashi Iwai wrote:
Sounds good - I will test in the next day or so and report back. What's the most efficient way to get hold of this tree / branch given that I have the for-next branch of sound.git? Can I somehow leverage this, or do I need to do a completely separate checkout? Apologies if this is a basic question - I'm still coming to terms with git.
sound-unstable git tree always contains the sound git tree master branch, so everything is there basically. ...
What's the next step in the process? I've reported the outcome of the tests of sound-unstable as per that report progress is being made. Is it a case of waiting for things to stabilise, or do you need me to do something to move things along? If so, what?
I merged the patches to the main sound git tree for-next branch now.
Also a few updates are merged there, too: now the hp mic jack mode should be able to change the pin control no matter whether which capture source is. Also, the capture source won't change the hp/mic pinctl when the jack mode enum is created. This reduces the automation but also reduces the confusion, too. After all, when jack mode is present, user wants to control the pin by himself.
Let me know if anything else is missing or broken.
I've given this new revision a quick test; sorry for the delay. With this revision, when using "model=fujitsu-jwse" things seem to be working pretty well. In particular, the updates you mention greatly improve usability; the lack of automatic interaction between mixer controls makes it much easier to use and understand.
I think everything is present and accounted for in this latest revision. Thanks for your work on this.
The only slightly odd thing I noticed was that whenever the driver is loaded the "headphone mic jack mode" defaults to "mic bias 80pc", rather than "line out" or "headphone" which I would have expected. Obviously this can be manually or automatically overridden after module load, but in many ways it would be good if it defaulted to one of the output modes (given that the jack's primary purpose is for output).
Indeed, it's an overlooked bug. I merged the fix patch below.
Where does this leave us now? Is the "fujitsu-jwse" a permanent thing, or will the respective changes be rolled into something more generic?
I'm inclined to keep as is.
thanks,
Takashi
--- Subject: [PATCH] ALSA: hda - Don't re-initialize shared hp/mic pinctl
When a headphone pin is set up as a shared hp/mic pin, we rather want to keep it as a headphone primarily as default, but the driver overrides it always as a mic pin, just because the input controls are created after outputs. Add a check of pin NID and skip the re-initialization of pinctl for such a shared hp/mic pin.
Reported-by: Jonathan Woithe jwoithe@just42.net Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/hda_generic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index fb232c1..aae6b10 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -2967,7 +2967,8 @@ static int create_input_ctls(struct hda_codec *codec) val = PIN_IN; if (cfg->inputs[i].type == AUTO_PIN_MIC) val |= snd_hda_get_default_vref(codec, pin); - set_pin_target(codec, pin, val, false); + if (pin != spec->hp_mic_pin) + set_pin_target(codec, pin, val, false);
if (mixer) { if (is_reachable_path(codec, pin, mixer)) {
On Mon, Mar 11, 2013 at 09:52:38AM +0100, Takashi Iwai wrote:
At Sun, 10 Mar 2013 15:28:54 +1030, Jonathan Woithe wrote:
The only slightly odd thing I noticed was that whenever the driver is loaded the "headphone mic jack mode" defaults to "mic bias 80pc", rather than "line out" or "headphone" which I would have expected. Obviously this can be manually or automatically overridden after module load, but in many ways it would be good if it defaulted to one of the output modes (given that the jack's primary purpose is for output).
Indeed, it's an overlooked bug. I merged the fix patch below.
That looks like it'll do the trick. I'll check it explicitly when I get a chance over the next few days.
Where does this leave us now? Is the "fujitsu-jwse" a permanent thing, or will the respective changes be rolled into something more generic?
I'm inclined to keep as is.
Ok, suits me.
Do you think that a more descriptive model (eg: fujitsu-fullmixer or something) is warranted?
BTW, I will attempt to determine precisely what it is about the default initialisation sequence that causes the internal speaker to be permanently muted. For now though the workarounds in "fujitsu-jwse" work well.
Regards jonathan
participants (2)
-
Jonathan Woithe -
Takashi Iwai