ALSA: HDA: Fix microphone(s) on Lenovo Edge 13
PATCH 1/1 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! :-)
Signature · 2 lines
David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
Quoted 1 line
From
c8c0ca221b4de97682d2e9e5ad73c0ac6346b398Mon Sep 17 00:00:00 2001
From: David Henningsson <[email protected]>
Date: Thu, 27 Jan 2011 10:28:46 +0100
Subject: [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.
--- sound/pci/hda/patch_conexant.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
sound/pci/hda/patch_conexant.c +1 -0
@@ -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 ),SND_PCI_QUIRK (0x17aa ,0x215e ,"Lenovo Thinkpad" ,CXT5066_THINKPAD ),SND_PCI_QUIRK (0x17aa ,0x38af ,"Lenovo G560" ,CXT5066_ASUS ), SND_PCI_QUIRK_VENDOR(0x17aa, "Lenovo", CXT5066_IDEAPAD), /* Fallback for Lenovos without dock mic */
Signature · 1 line
1.7.1
_______________________________________________
Alsa-devel mailing list
[email protected]
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Thu, 27 Jan 2011 10:37:02 +0100,
Quoted 21 lines · David Henningsson
Quoted 2 lines
From
c8c0ca221b4de97682d2e9e5ad73c0ac6346b398Mon Sep 17 00:00:00 2001From: David Henningsson <[email protected]>
Date: Thu, 27 Jan 2011 10:28:46 +0100
Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13This Edge 13 model has an internal mic at
0x1aand should therefore use the asus quirk.Signed-off-by David Henningsson <[email protected]>--- sound/pci/hda/patch_conexant.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)sound/pci/hda/patch_conexant.c +0
-0
sound/pci/hda/patch_conexant.c static struct snd_pci_quirk cxt5066_cfg_tbl[] = { · line 3123
Quoted 4 lines
sound/pci/hda/patch_conexant.c +1
-0@@ -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
Quoted 18 lines · Takashi Iwai
At Thu, 27 Jan 2011 10:37:02 +0100,
Quoted 16 lines · David Henningsson
Quoted 2 lines
From
c8c0ca221b4de97682d2e9e5ad73c0ac6346b398Mon Sep 17 00:00:00 2001From: David Henningsson<[email protected]>
Date: Thu, 27 Jan 2011 10:28:46 +0100
Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13This Edge 13 model has an internal mic at
0x1aand should therefore use the asus quirk.Signed-off-by David Henningsson<[email protected]>--- sound/pci/hda/patch_conexant.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
Quoted 11 lines
sound/pci/hda/patch_conexant.c static struct snd_pci_quirk cxt5066_cfg_tbl[] = { · line 3123
Quoted 9 lines
sound/pci/hda/patch_conexant.c +1
-0@@ -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.
Quoted 4 lines
This should be merged, I guess.
I applided the patch but currently it's for 2.6.39 since
CXT5066_ASUSchanges 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?
Quoted 4 lines
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.
Signature · 2 lines
David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
At Fri, 28 Jan 2011 12:51:30 +0100,
Quoted 34 lines · David Henningsson
Quoted 18 lines · Takashi Iwai
At Thu, 27 Jan 2011 10:37:02 +0100,
Quoted 16 lines · David Henningsson
Quoted 2 lines
From
c8c0ca221b4de97682d2e9e5ad73c0ac6346b398Mon Sep 17 00:00:00 2001From: David Henningsson<[email protected]>
Date: Thu, 27 Jan 2011 10:28:46 +0100
Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13This Edge 13 model has an internal mic at
0x1aand should therefore use the asus quirk.Signed-off-by David Henningsson<[email protected]>--- sound/pci/hda/patch_conexant.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)Quoted 11 lines
sound/pci/hda/patch_conexant.c static struct snd_pci_quirk cxt5066_cfg_tbl[] = { · line 3123
Quoted 9 lines
sound/pci/hda/patch_conexant.c +1
-0@@ -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.
Quoted 7 lines
Quoted 4 lines
This should be merged, I guess.
I applided the patch but currently it's for 2.6.39 since
CXT5066_ASUSchanges 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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 35 lines · Takashi Iwai
At Fri, 28 Jan 2011 12:51:30 +0100,
Quoted 33 lines · David Henningsson
Quoted 18 lines · Takashi Iwai
At Thu, 27 Jan 2011 10:37:02 +0100,
Quoted 16 lines · David Henningsson
Quoted 2 lines
From
c8c0ca221b4de97682d2e9e5ad73c0ac6346b398Mon Sep 17 00:00:00 2001From: David Henningsson<[email protected]>
Date: Thu, 27 Jan 2011 10:28:46 +0100
Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13This Edge 13 model has an internal mic at
0x1aand should therefore use the asus quirk.Signed-off-by David Henningsson<[email protected]>--- sound/pci/hda/patch_conexant.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)Quoted 11 lines
sound/pci/hda/patch_conexant.c static struct snd_pci_quirk cxt5066_cfg_tbl[] = { · line 3123
Quoted 9 lines
sound/pci/hda/patch_conexant.c +1
-0@@ -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.
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
This should be merged, I guess.
I applided the patch but currently it's for 2.6.39 since
CXT5066_ASUSchanges aren't queued for 2.6.38 (as non-trivial changes).
Quoted 8 lines
Quoted 2 lines
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.
Signature · 2 lines
David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
At Fri, 28 Jan 2011 13:40:34 +0100,
Quoted 52 lines · David Henningsson
Quoted 35 lines · Takashi Iwai
At Fri, 28 Jan 2011 12:51:30 +0100,
Quoted 33 lines · David Henningsson
Quoted 18 lines · Takashi Iwai
At Thu, 27 Jan 2011 10:37:02 +0100,
Quoted 16 lines · David Henningsson
Quoted 2 lines
From
c8c0ca221b4de97682d2e9e5ad73c0ac6346b398Mon Sep 17 00:00:00 2001From: David Henningsson<[email protected]>
Date: Thu, 27 Jan 2011 10:28:46 +0100
Subject: [PATCH] ALSA: HDA: Fix microphone(s) on Lenovo Edge 13This Edge 13 model has an internal mic at
0x1aand should therefore use the asus quirk.Signed-off-by David Henningsson<[email protected]>--- sound/pci/hda/patch_conexant.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)Quoted 11 lines
sound/pci/hda/patch_conexant.c static struct snd_pci_quirk cxt5066_cfg_tbl[] = { · line 3123
Quoted 9 lines
sound/pci/hda/patch_conexant.c +1
-0@@ -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.Quoted 11 lines
Quoted 8 lines
Quoted 5 lines
This should be merged, I guess.
I applided the patch but currently it's for 2.6.39 since
CXT5066_ASUSchanges 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.
Quoted 7 lines
Quoted 3 lines
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
Codecs without auto-parser (was: ALSA: HDA: Fix microphone(s) on Lenovo Edge 13)
In reply to Takashi IwaiQuoted 9 lines · Takashi Iwai
At Fri, 28 Jan 2011 12:51:30 +0100,
Quoted 7 lines · David Henningsson
Quoted 4 lines · Takashi Iwai
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.
Quoted 4 lines
Quoted 2 lines
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 (?).
Signature · 2 lines
David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
Re: Codecs without auto-parser (was: ALSA: HDA: Fix microphone(s) on Lenovo Edge 13)
At Tue, 01 Feb 2011 08:37:25 +0100,
Quoted 11 lines · David Henningsson
Quoted 9 lines · Takashi Iwai
At Fri, 28 Jan 2011 12:51:30 +0100,
Quoted 7 lines · David Henningsson
Quoted 4 lines · Takashi Iwai
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.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 3 lines
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...
Quoted 8 lines
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.
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.
Quoted 6 lines
2) It seems to me like the most competent candidate for auto-parser currently is the
cx_autostuff - 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 tohda_codec.cin 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.
Quoted 3 lines
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 (?).
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
Re: Codecs without auto-parser
Quoted 43 lines · Takashi Iwai
At Tue, 01 Feb 2011 08:37:25 +0100,
Quoted 11 lines · David Henningsson
Quoted 9 lines · Takashi Iwai
At Fri, 28 Jan 2011 12:51:30 +0100,
Quoted 7 lines · David Henningsson
Quoted 4 lines · Takashi Iwai
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.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 3 lines
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...
Quoted 8 lines
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.
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.
Quoted 6 lines
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.
Quoted 12 lines
Quoted 6 lines
2) It seems to me like the most competent candidate for auto-parser currently is the
cx_autostuff - 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 tohda_codec.cin 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.
Quoted 6 lines
Quoted 3 lines
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 (?).
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?
Signature · 2 lines
David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
Re: Codecs without auto-parser
At Wed, 02 Feb 2011 16:16:21 +0100,
Quoted 71 lines · David Henningsson
Quoted 43 lines · Takashi Iwai
At Tue, 01 Feb 2011 08:37:25 +0100,
Quoted 11 lines · David Henningsson
Quoted 9 lines · Takashi Iwai
At Fri, 28 Jan 2011 12:51:30 +0100,
Quoted 7 lines · David Henningsson
Quoted 4 lines · Takashi Iwai
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.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 3 lines
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...
Quoted 8 lines
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.
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.
Quoted 6 lines
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.
Quoted 16 lines
Quoted 6 lines
2) It seems to me like the most competent candidate for auto-parser currently is the
cx_autostuff - 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 tohda_codec.cin 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.
Quoted 3 lines
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 (?).
Quoted 5 lines
Quoted 2 lines
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 :)
Quoted 11 lines
I'm looking at
fill_cx_auto_dacs. That doesn't look like Conexant specific stuff at all.cx_auto_hp_automutelooks quite generic as well, except for a pointer deref in the beginning.cx_auto_build_output_controlscould be merged withxxxx_create_multi_out_ctlspresent in the Realtek and Analog parsers. And so on.Shouldn't we move and rename
fill_cx_auto_dacstohda_codec.cand 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.
Quoted 5 lines
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
Re: Codecs without auto-parser
Quoted 106 lines · Takashi Iwai
At Wed, 02 Feb 2011 16:16:21 +0100,
Quoted 71 lines · David Henningsson
Quoted 43 lines · Takashi Iwai
At Tue, 01 Feb 2011 08:37:25 +0100,
Quoted 11 lines · David Henningsson
Quoted 9 lines · Takashi Iwai
At Fri, 28 Jan 2011 12:51:30 +0100,
Quoted 7 lines · David Henningsson
Quoted 4 lines · Takashi Iwai
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.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 3 lines
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...
Quoted 8 lines
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.
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.
Quoted 6 lines
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.
Quoted 16 lines
Quoted 6 lines
2) It seems to me like the most competent candidate for auto-parser currently is the
cx_autostuff - 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 tohda_codec.cin 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.
Quoted 3 lines
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 (?).
Quoted 5 lines
Quoted 2 lines
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 :)
Quoted 11 lines
I'm looking at
fill_cx_auto_dacs. That doesn't look like Conexant specific stuff at all.cx_auto_hp_automutelooks quite generic as well, except for a pointer deref in the beginning.cx_auto_build_output_controlscould be merged withxxxx_create_multi_out_ctlspresent in the Realtek and Analog parsers. And so on.Shouldn't we move and rename
fill_cx_auto_dacstohda_codec.cand 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.
Quoted 5 lines
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?
Quoted 3 lines
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...
Signature · 2 lines
David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
Quoted 4 lines · Takashi Iwai
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.