[alsa-devel] [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
This Edge 13 model has an internal mic at 0x1a and should therefore use the asus quirk.
Since my backport of the asus model is now tested and working, would it be possible to apply that patch as well as this quirk to 2.6.38?
Thanks Takashi for keeping up with all the patches coming in! :-)
At Thu, 27 Jan 2011 10:37:02 +0100, David Henningsson wrote:
From c8c0ca221b4de97682d2e9e5ad73c0ac6346b398 Mon Sep 17 00:00:00 2001
From: David Henningsson david.henningsson@canonical.com Date: Thu, 27 Jan 2011 10:28:46 +0100 Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
BugLink: http://bugs.launchpad.net/bugs/708521
This Edge 13 model has an internal mic at 0x1a and should therefore use the asus quirk.
Signed-off-by: David Henningsson david.henningsson@canonical.com
sound/pci/hda/patch_conexant.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 9867afc..7e1ca43 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -3120,6 +3120,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = { SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5), SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400s", CXT5066_THINKPAD), SND_PCI_QUIRK(0x17aa, 0x21c5, "Thinkpad Edge 13", CXT5066_THINKPAD),
- SND_PCI_QUIRK(0x17aa, 0x21c6, "Thinkpad Edge 13", CXT5066_ASUS),
Can 21c5 and 21c6 be incompatible models? This should be merged, I guess.
I applided the patch but currently it's for 2.6.39 since CXT5066_ASUS changes aren't queued for 2.6.38 (as non-trivial changes).
And I hope that we should go further a bit for now -- more clean up of the cxt5066 code either checking BIOS pins or hp/mic/spk pre-defined pins. Currently, the code is fairly messy (partly because of olpc support), and now is a good chance to improve it a bit more.
thanks,
Takashi
On 2011-01-28 09:01, Takashi Iwai wrote:
At Thu, 27 Jan 2011 10:37:02 +0100, David Henningsson wrote:
From c8c0ca221b4de97682d2e9e5ad73c0ac6346b398 Mon Sep 17 00:00:00 2001
From: David Henningssondavid.henningsson@canonical.com Date: Thu, 27 Jan 2011 10:28:46 +0100 Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
BugLink: http://bugs.launchpad.net/bugs/708521
This Edge 13 model has an internal mic at 0x1a and should therefore use the asus quirk.
Signed-off-by: David Henningssondavid.henningsson@canonical.com
sound/pci/hda/patch_conexant.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 9867afc..7e1ca43 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -3120,6 +3120,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = { SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5), SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400s", CXT5066_THINKPAD), SND_PCI_QUIRK(0x17aa, 0x21c5, "Thinkpad Edge 13", CXT5066_THINKPAD),
- SND_PCI_QUIRK(0x17aa, 0x21c6, "Thinkpad Edge 13", CXT5066_ASUS),
Can 21c5 and 21c6 be incompatible models?
Good question. Seems like Manoj committed that one, I'll ask him about it.
This should be merged, I guess.
I applided the patch but currently it's for 2.6.39 since CXT5066_ASUS changes aren't queued for 2.6.38 (as non-trivial changes).
Sorry, I was under the impression that you would accept a backport for 2.6.38, as you said in the earlier email?
And I hope that we should go further a bit for now -- more clean up of the cxt5066 code either checking BIOS pins or hp/mic/spk pre-defined pins. Currently, the code is fairly messy (partly because of olpc support), and now is a good chance to improve it a bit more.
Maybe so. I'm not sure I can commit to doing that work right now, as I have other work commitments waiting for me to take care of them.
At Fri, 28 Jan 2011 12:51:30 +0100, David Henningsson wrote:
On 2011-01-28 09:01, Takashi Iwai wrote:
At Thu, 27 Jan 2011 10:37:02 +0100, David Henningsson wrote:
From c8c0ca221b4de97682d2e9e5ad73c0ac6346b398 Mon Sep 17 00:00:00 2001
From: David Henningssondavid.henningsson@canonical.com Date: Thu, 27 Jan 2011 10:28:46 +0100 Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
BugLink: http://bugs.launchpad.net/bugs/708521
This Edge 13 model has an internal mic at 0x1a and should therefore use the asus quirk.
Signed-off-by: David Henningssondavid.henningsson@canonical.com
sound/pci/hda/patch_conexant.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 9867afc..7e1ca43 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -3120,6 +3120,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = { SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5), SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400s", CXT5066_THINKPAD), SND_PCI_QUIRK(0x17aa, 0x21c5, "Thinkpad Edge 13", CXT5066_THINKPAD),
- SND_PCI_QUIRK(0x17aa, 0x21c6, "Thinkpad Edge 13", CXT5066_ASUS),
Can 21c5 and 21c6 be incompatible models?
Good question. Seems like Manoj committed that one, I'll ask him about it.
This should be merged, I guess.
I applided the patch but currently it's for 2.6.39 since CXT5066_ASUS changes aren't queued for 2.6.38 (as non-trivial changes).
Sorry, I was under the impression that you would accept a backport for 2.6.38, as you said in the earlier email?
Ah, no. I didn't mean that. Sorry not being clear enough.
Moving the commits from 2.6.39 tree is possible but a bit mess because of rebase, thus I'd like to avoid it, unless it's urgently needed.
And I hope that we should go further a bit for now -- more clean up of the cxt5066 code either checking BIOS pins or hp/mic/spk pre-defined pins. Currently, the code is fairly messy (partly because of olpc support), and now is a good chance to improve it a bit more.
Maybe so. I'm not sure I can commit to doing that work right now, as I have other work commitments waiting for me to take care of them.
OK.
thanks,
Takashi
On 2011-01-28 13:10, Takashi Iwai wrote:
At Fri, 28 Jan 2011 12:51:30 +0100, David Henningsson wrote:
On 2011-01-28 09:01, Takashi Iwai wrote:
At Thu, 27 Jan 2011 10:37:02 +0100, David Henningsson wrote:
From c8c0ca221b4de97682d2e9e5ad73c0ac6346b398 Mon Sep 17 00:00:00 2001
From: David Henningssondavid.henningsson@canonical.com Date: Thu, 27 Jan 2011 10:28:46 +0100 Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
BugLink: http://bugs.launchpad.net/bugs/708521
This Edge 13 model has an internal mic at 0x1a and should therefore use the asus quirk.
Signed-off-by: David Henningssondavid.henningsson@canonical.com
sound/pci/hda/patch_conexant.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 9867afc..7e1ca43 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -3120,6 +3120,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = { SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5), SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400s", CXT5066_THINKPAD), SND_PCI_QUIRK(0x17aa, 0x21c5, "Thinkpad Edge 13", CXT5066_THINKPAD),
- SND_PCI_QUIRK(0x17aa, 0x21c6, "Thinkpad Edge 13", CXT5066_ASUS),
Can 21c5 and 21c6 be incompatible models?
Good question. Seems like Manoj committed that one, I'll ask him about it.
I followed the buglink for Manoj's commit and found an internal mic at node 0x1a, so it's likely it should be changed to the asus model.
This should be merged, I guess.
I applided the patch but currently it's for 2.6.39 since CXT5066_ASUS changes aren't queued for 2.6.38 (as non-trivial changes).
Sorry, I was under the impression that you would accept a backport for 2.6.38, as you said in the earlier email?
Ah, no. I didn't mean that. Sorry not being clear enough.
Moving the commits from 2.6.39 tree is possible but a bit mess because of rebase, thus I'd like to avoid it, unless it's urgently needed.
Well, that's up to you - from my/Ubuntu's perspective, it's important to have it in 2.6.38 (Ubuntu 11.04 will have kernel 2.6.38), so if you don't, I'll just apply it downstream instead, in the Ubuntu kernel.
At Fri, 28 Jan 2011 13:40:34 +0100, David Henningsson wrote:
On 2011-01-28 13:10, Takashi Iwai wrote:
At Fri, 28 Jan 2011 12:51:30 +0100, David Henningsson wrote:
On 2011-01-28 09:01, Takashi Iwai wrote:
At Thu, 27 Jan 2011 10:37:02 +0100, David Henningsson wrote:
From c8c0ca221b4de97682d2e9e5ad73c0ac6346b398 Mon Sep 17 00:00:00 2001
From: David Henningssondavid.henningsson@canonical.com Date: Thu, 27 Jan 2011 10:28:46 +0100 Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
BugLink: http://bugs.launchpad.net/bugs/708521
This Edge 13 model has an internal mic at 0x1a and should therefore use the asus quirk.
Signed-off-by: David Henningssondavid.henningsson@canonical.com
sound/pci/hda/patch_conexant.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 9867afc..7e1ca43 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -3120,6 +3120,7 @@ static struct snd_pci_quirk cxt5066_cfg_tbl[] = { SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT5066_OLPC_XO_1_5), SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400s", CXT5066_THINKPAD), SND_PCI_QUIRK(0x17aa, 0x21c5, "Thinkpad Edge 13", CXT5066_THINKPAD),
- SND_PCI_QUIRK(0x17aa, 0x21c6, "Thinkpad Edge 13", CXT5066_ASUS),
Can 21c5 and 21c6 be incompatible models?
Good question. Seems like Manoj committed that one, I'll ask him about it.
I followed the buglink for Manoj's commit and found an internal mic at node 0x1a, so it's likely it should be changed to the asus model.
This should be merged, I guess.
I applided the patch but currently it's for 2.6.39 since CXT5066_ASUS changes aren't queued for 2.6.38 (as non-trivial changes).
Sorry, I was under the impression that you would accept a backport for 2.6.38, as you said in the earlier email?
Ah, no. I didn't mean that. Sorry not being clear enough.
Moving the commits from 2.6.39 tree is possible but a bit mess because of rebase, thus I'd like to avoid it, unless it's urgently needed.
Well, that's up to you - from my/Ubuntu's perspective, it's important to have it in 2.6.38 (Ubuntu 11.04 will have kernel 2.6.38), so if you don't, I'll just apply it downstream instead, in the Ubuntu kernel.
OK, I merged all the pending conexant fixes back to fix/hda branch for 2.6.38 tree, as fortunately there have been only clean fixes in topic/hda branch so far. It'll be included in the next pull request to Linus.
thanks,
Takashi
On 2011-01-28 13:10, Takashi Iwai wrote:
At Fri, 28 Jan 2011 12:51:30 +0100, David Henningsson wrote:
On 2011-01-28 09:01, Takashi Iwai wrote:
And I hope that we should go further a bit for now -- more clean up of the cxt5066 code either checking BIOS pins or hp/mic/spk pre-defined pins. Currently, the code is fairly messy (partly because of olpc support), and now is a good chance to improve it a bit more.
Maybe so. I'm not sure I can commit to doing that work right now, as I have other work commitments waiting for me to take care of them.
OK.
Hmm. I got a few things cleared up yesterday, and so I might have some time to actually do this. However, it also seems like I have to fix an AD1984A machine, and that driver is in equally bad shape (as in: no auto-parser, just a list of models). I could add another model, but suppose I'd do this the right way, how would I do it?
I guess there are three options to start off with:
1) ad1988 seems to have an auto-parser. There are a lot of hardcoded nids in there, but I guess I could copy-and-paste some into a new auto-parser for ad1984a.
2) It seems to me like the most competent candidate for auto-parser currently is the cx_auto stuff - compared to other auto-parsers the hardcoded nids are fewer. Perhaps this one could be extended to also do auto-parsing for codecs from other vendors? Or at least some convenience functions moved to hda_codec.c in order to remove duplication between vendors?
3) There is also the generic parser. It seems to be the one most capable of handling randomly complex graphs, but is lacking automute/jack-detect support, and maybe other functions as well (?).
At Tue, 01 Feb 2011 08:37:25 +0100, David Henningsson wrote:
On 2011-01-28 13:10, Takashi Iwai wrote:
At Fri, 28 Jan 2011 12:51:30 +0100, David Henningsson wrote:
On 2011-01-28 09:01, Takashi Iwai wrote:
And I hope that we should go further a bit for now -- more clean up of the cxt5066 code either checking BIOS pins or hp/mic/spk pre-defined pins. Currently, the code is fairly messy (partly because of olpc support), and now is a good chance to improve it a bit more.
Maybe so. I'm not sure I can commit to doing that work right now, as I have other work commitments waiting for me to take care of them.
OK.
Hmm. I got a few things cleared up yesterday, and so I might have some time to actually do this.
Great.
However, it also seems like I have to fix an AD1984A machine, and that driver is in equally bad shape (as in: no auto-parser, just a list of models).
Yeah, I know...
I could add another model, but suppose I'd do this the right way, how would I do it?
I guess there are three options to start off with:
- ad1988 seems to have an auto-parser. There are a lot of hardcoded
nids in there, but I guess I could copy-and-paste some into a new auto-parser for ad1984a.
Well... AD1988 and AD1984A aren't so similar, IIRC. AD1984A is more straightforward hardware implementation while AD1988 can have more connections. Also AD1988 auto-parser isn't in the best form in comparison with other codecs.
That being said, if AD1984A can fit with AD1988's auto-parser (i.e. my memory was too vague), it's fine. We can adapt it.
If this is hard, one more quirk model won't be too bad for AD1984A since this is a pretty simple codec, and there won't be so more devices with this old chip.
- It seems to me like the most competent candidate for auto-parser
currently is the cx_auto stuff - compared to other auto-parsers the hardcoded nids are fewer. Perhaps this one could be extended to also do auto-parsing for codecs from other vendors? Or at least some convenience functions moved to hda_codec.c in order to remove duplication between vendors?
Yes, I can loudly tell people "I have a dream, unify all codec parsers!" :) But, I'm afraid that a big hammer doesn't work. The topology is fairly different between codecs, and resolving all makes the parser complex. So, some hints would be needed to simplify the logic, after all.
- There is also the generic parser. It seems to be the one most capable
of handling randomly complex graphs, but is lacking automute/jack-detect support, and maybe other functions as well (?).
The generic parser is the very first parser, and it never worked rightly. This should be really replaced with a more clever one.
thanks,
Takashi
On 2011-02-01 22:34, Takashi Iwai wrote:
At Tue, 01 Feb 2011 08:37:25 +0100, David Henningsson wrote:
On 2011-01-28 13:10, Takashi Iwai wrote:
At Fri, 28 Jan 2011 12:51:30 +0100, David Henningsson wrote:
On 2011-01-28 09:01, Takashi Iwai wrote:
And I hope that we should go further a bit for now -- more clean up of the cxt5066 code either checking BIOS pins or hp/mic/spk pre-defined pins. Currently, the code is fairly messy (partly because of olpc support), and now is a good chance to improve it a bit more.
Maybe so. I'm not sure I can commit to doing that work right now, as I have other work commitments waiting for me to take care of them.
OK.
Hmm. I got a few things cleared up yesterday, and so I might have some time to actually do this.
Great.
However, it also seems like I have to fix an AD1984A machine, and that driver is in equally bad shape (as in: no auto-parser, just a list of models).
Yeah, I know...
I could add another model, but suppose I'd do this the right way, how would I do it?
I guess there are three options to start off with:
- ad1988 seems to have an auto-parser. There are a lot of hardcoded
nids in there, but I guess I could copy-and-paste some into a new auto-parser for ad1984a.
Well... AD1988 and AD1984A aren't so similar, IIRC. AD1984A is more straightforward hardware implementation while AD1988 can have more connections. Also AD1988 auto-parser isn't in the best form in comparison with other codecs.
That being said, if AD1984A can fit with AD1988's auto-parser (i.e. my memory was too vague), it's fine. We can adapt it.
If this is hard, one more quirk model won't be too bad for AD1984A since this is a pretty simple codec, and there won't be so more devices with this old chip.
Ok. I had one more look at AD1988's auto-parser and I don't think it's good to start off that one.
- It seems to me like the most competent candidate for auto-parser
currently is the cx_auto stuff - compared to other auto-parsers the hardcoded nids are fewer. Perhaps this one could be extended to also do auto-parsing for codecs from other vendors? Or at least some convenience functions moved to hda_codec.c in order to remove duplication between vendors?
Yes, I can loudly tell people "I have a dream, unify all codec parsers!" :) But, I'm afraid that a big hammer doesn't work. The topology is fairly different between codecs, and resolving all makes the parser complex. So, some hints would be needed to simplify the logic, after all.
- There is also the generic parser. It seems to be the one most capable
of handling randomly complex graphs, but is lacking automute/jack-detect support, and maybe other functions as well (?).
The generic parser is the very first parser, and it never worked rightly. This should be really replaced with a more clever one.
Hrmm...am I the only one thinking that your answer to 2) and 3) are in direct contradiction? :-)
I'm looking at fill_cx_auto_dacs. That doesn't look like Conexant specific stuff at all. cx_auto_hp_automute looks quite generic as well, except for a pointer deref in the beginning. cx_auto_build_output_controls could be merged with xxxx_create_multi_out_ctls present in the Realtek and Analog parsers. And so on.
Shouldn't we move and rename fill_cx_auto_dacs to hda_codec.c and use it for all codecs, instead of hardcoding dac nids everywhere? At least in general? (There might be exceptions, where there is a dac you don't want to use.)
Anyway, you wanted some work done to Conexant 5066. Could you clarify that a little? You likely want to call snd_hda_parse_pin_def_config - but are you expecting yet another auto-parser after that? Or just to choose model based on the result? And should we remove all the model quirks (except possibly for OLPC) afterwards?
At Wed, 02 Feb 2011 16:16:21 +0100, David Henningsson wrote:
On 2011-02-01 22:34, Takashi Iwai wrote:
At Tue, 01 Feb 2011 08:37:25 +0100, David Henningsson wrote:
On 2011-01-28 13:10, Takashi Iwai wrote:
At Fri, 28 Jan 2011 12:51:30 +0100, David Henningsson wrote:
On 2011-01-28 09:01, Takashi Iwai wrote:
And I hope that we should go further a bit for now -- more clean up of the cxt5066 code either checking BIOS pins or hp/mic/spk pre-defined pins. Currently, the code is fairly messy (partly because of olpc support), and now is a good chance to improve it a bit more.
Maybe so. I'm not sure I can commit to doing that work right now, as I have other work commitments waiting for me to take care of them.
OK.
Hmm. I got a few things cleared up yesterday, and so I might have some time to actually do this.
Great.
However, it also seems like I have to fix an AD1984A machine, and that driver is in equally bad shape (as in: no auto-parser, just a list of models).
Yeah, I know...
I could add another model, but suppose I'd do this the right way, how would I do it?
I guess there are three options to start off with:
- ad1988 seems to have an auto-parser. There are a lot of hardcoded
nids in there, but I guess I could copy-and-paste some into a new auto-parser for ad1984a.
Well... AD1988 and AD1984A aren't so similar, IIRC. AD1984A is more straightforward hardware implementation while AD1988 can have more connections. Also AD1988 auto-parser isn't in the best form in comparison with other codecs.
That being said, if AD1984A can fit with AD1988's auto-parser (i.e. my memory was too vague), it's fine. We can adapt it.
If this is hard, one more quirk model won't be too bad for AD1984A since this is a pretty simple codec, and there won't be so more devices with this old chip.
Ok. I had one more look at AD1988's auto-parser and I don't think it's good to start off that one.
- It seems to me like the most competent candidate for auto-parser
currently is the cx_auto stuff - compared to other auto-parsers the hardcoded nids are fewer. Perhaps this one could be extended to also do auto-parsing for codecs from other vendors? Or at least some convenience functions moved to hda_codec.c in order to remove duplication between vendors?
Yes, I can loudly tell people "I have a dream, unify all codec parsers!" :) But, I'm afraid that a big hammer doesn't work. The topology is fairly different between codecs, and resolving all makes the parser complex. So, some hints would be needed to simplify the logic, after all.
- There is also the generic parser. It seems to be the one most capable
of handling randomly complex graphs, but is lacking automute/jack-detect support, and maybe other functions as well (?).
The generic parser is the very first parser, and it never worked rightly. This should be really replaced with a more clever one.
Hrmm...am I the only one thinking that your answer to 2) and 3) are in direct contradiction? :-)
The reality is bitter, you know :)
I'm looking at fill_cx_auto_dacs. That doesn't look like Conexant specific stuff at all. cx_auto_hp_automute looks quite generic as well, except for a pointer deref in the beginning. cx_auto_build_output_controls could be merged with xxxx_create_multi_out_ctls present in the Realtek and Analog parsers. And so on.
Shouldn't we move and rename fill_cx_auto_dacs to hda_codec.c and use it for all codecs, instead of hardcoding dac nids everywhere? At least in general? (There might be exceptions, where there is a dac you don't want to use.)
Well, Conexant auto-parser is a fairly recent one I wrote, so it's more or less generic. But there are still a few glitches that Conexant parser doesn't handle properly, IIRC.
We can give it a try with different codecs using hda-emu to see what doesn't fit.
Anyway, you wanted some work done to Conexant 5066. Could you clarify that a little? You likely want to call snd_hda_parse_pin_def_config - but are you expecting yet another auto-parser after that? Or just to choose model based on the result? And should we remove all the model quirks (except possibly for OLPC) afterwards?
My initial idea was to adapt the current Conexant parser for 5066. If it doesn't work by some reason, adjust the code, then replaces the model quirks with the pin-config presets.
However, OLPC is a big exception. So, this will likely stay as is.
thanks,
Takashi
On 2011-02-03 14:16, Takashi Iwai wrote:
At Wed, 02 Feb 2011 16:16:21 +0100, David Henningsson wrote:
On 2011-02-01 22:34, Takashi Iwai wrote:
At Tue, 01 Feb 2011 08:37:25 +0100, David Henningsson wrote:
On 2011-01-28 13:10, Takashi Iwai wrote:
At Fri, 28 Jan 2011 12:51:30 +0100, David Henningsson wrote:
On 2011-01-28 09:01, Takashi Iwai wrote: > And I hope that we should go further a bit for now -- more clean up of > the cxt5066 code either checking BIOS pins or hp/mic/spk pre-defined > pins. Currently, the code is fairly messy (partly because of olpc > support), and now is a good chance to improve it a bit more.
Maybe so. I'm not sure I can commit to doing that work right now, as I have other work commitments waiting for me to take care of them.
OK.
Hmm. I got a few things cleared up yesterday, and so I might have some time to actually do this.
Great.
However, it also seems like I have to fix an AD1984A machine, and that driver is in equally bad shape (as in: no auto-parser, just a list of models).
Yeah, I know...
I could add another model, but suppose I'd do this the right way, how would I do it?
I guess there are three options to start off with:
- ad1988 seems to have an auto-parser. There are a lot of hardcoded
nids in there, but I guess I could copy-and-paste some into a new auto-parser for ad1984a.
Well... AD1988 and AD1984A aren't so similar, IIRC. AD1984A is more straightforward hardware implementation while AD1988 can have more connections. Also AD1988 auto-parser isn't in the best form in comparison with other codecs.
That being said, if AD1984A can fit with AD1988's auto-parser (i.e. my memory was too vague), it's fine. We can adapt it.
If this is hard, one more quirk model won't be too bad for AD1984A since this is a pretty simple codec, and there won't be so more devices with this old chip.
Ok. I had one more look at AD1988's auto-parser and I don't think it's good to start off that one.
- It seems to me like the most competent candidate for auto-parser
currently is the cx_auto stuff - compared to other auto-parsers the hardcoded nids are fewer. Perhaps this one could be extended to also do auto-parsing for codecs from other vendors? Or at least some convenience functions moved to hda_codec.c in order to remove duplication between vendors?
Yes, I can loudly tell people "I have a dream, unify all codec parsers!" :) But, I'm afraid that a big hammer doesn't work. The topology is fairly different between codecs, and resolving all makes the parser complex. So, some hints would be needed to simplify the logic, after all.
- There is also the generic parser. It seems to be the one most capable
of handling randomly complex graphs, but is lacking automute/jack-detect support, and maybe other functions as well (?).
The generic parser is the very first parser, and it never worked rightly. This should be really replaced with a more clever one.
Hrmm...am I the only one thinking that your answer to 2) and 3) are in direct contradiction? :-)
The reality is bitter, you know :)
I'm looking at fill_cx_auto_dacs. That doesn't look like Conexant specific stuff at all. cx_auto_hp_automute looks quite generic as well, except for a pointer deref in the beginning. cx_auto_build_output_controls could be merged with xxxx_create_multi_out_ctls present in the Realtek and Analog parsers. And so on.
Shouldn't we move and rename fill_cx_auto_dacs to hda_codec.c and use it for all codecs, instead of hardcoding dac nids everywhere? At least in general? (There might be exceptions, where there is a dac you don't want to use.)
Well, Conexant auto-parser is a fairly recent one I wrote, so it's more or less generic. But there are still a few glitches that Conexant parser doesn't handle properly, IIRC.
We can give it a try with different codecs using hda-emu to see what doesn't fit.
Anyway, you wanted some work done to Conexant 5066. Could you clarify that a little? You likely want to call snd_hda_parse_pin_def_config - but are you expecting yet another auto-parser after that? Or just to choose model based on the result? And should we remove all the model quirks (except possibly for OLPC) afterwards?
My initial idea was to adapt the current Conexant parser for 5066. If it doesn't work by some reason, adjust the code, then replaces the model quirks with the pin-config presets.
Ok. While waiting for your answer I continued thinking and writing a little code - here's how I would see a generic version of auto_parse_output:
1) Make a breadth-first-search, starting at each (output) pin, to find what DACs are reachable from each pin.
2) Start assigning DACs to pins, start off with line-outs (similar to what cx_auto does today). If HP's and Speakers can't have their own DACs, they'll have to share with their line-out counterpart (usually Front).
3) Investigate path from pin to DAC and add mute switches as close to the pin:s as possible.
4) Add volume controls on all capable widgets that are a part of the path. For 3 and 4 the naming must be decided based on what paths they are a part of.
(On top of that, add a quirk system that works with snd_hda_codec_read so that any command can be overridden to returned a fixed value instead. That quirk system could then be used to not only override pin configs but also remove paths so the above algorithm does not discover them, and other things.)
What do you think? Maybe I should give up these thoughts for now and just go with your suggestion...but then I would still have to fix that model for AD1984a...
On Fri, Jan 28, 2011 at 3:01 AM, Takashi Iwai tiwai@suse.de wrote:
And I hope that we should go further a bit for now -- more clean up of the cxt5066 code either checking BIOS pins or hp/mic/spk pre-defined pins. Currently, the code is fairly messy (partly because of olpc support), and now is a good chance to improve it a bit more.
The parsing code that was put in place for the CX206xx almost works for the cxt5066 as well, except that it does not handle inputs connected to the audio selector. Would it be better to add more auto-configuration to the cxt5066 code, or to enhance the CX206xx code to make it work with the cxt5066? I suppose the cxt5066 code is more mature at this point, so enhancing the cxt5066 code might have less risk of breaking something.
Also, it looks like there's a bug in cx_auto_check_auto_mic. Both "if" statements are checking if cfg->inputs[0].pin is an external mic and cfg->inputs[1].pin is an internal mic. The first one should be doing the opposite.
participants (3)
-
Andy Robinson -
David Henningsson -
Takashi Iwai