On 08/02/2015 03:17 PM, Takashi Iwai wrote:
On Fri, 31 Jul 2015 03:54:55 +0200, Hui Wang wrote:
On 07/30/2015 09:57 PM, Takashi Iwai wrote:
On Thu, 30 Jul 2015 12:11:00 +0200, Hui Wang wrote:
On 07/27/2015 06:52 PM, Takashi Iwai wrote:
On Mon, 27 Jul 2015 12:34:31 +0200, woodrow.shen@canonical.com wrote:
From: Woodrow Shen woodrow.shen@canonical.com
The new Dell laptop with codec 256 can't detect headset mic when headset was inserted on the machine. From alsa-info, we check init_pin_configs and need to define the new register value for pin 0x1d & 0x1e because the original macro ALC256_STANDARD_PINS can't match pin definition. Also, the macro ALC256_STANDARD_PINS is simplified by removing them. This makes headset mic works on laptop.
Codec: Realtek ALC256 Vendor Id: 0x10ec0256 Subsystem Id: 0x102806f2
BugLink: https://bugs.launchpad.net/bugs/1478497 Signed-off-by: Woodrow Shen woodrow.shen@canonical.com
I applied this as is now. But the code there is already messy, and I wonder whether we should treat all 0x4xxxxxxx equally. So far, all pincfgs are regarded as a kind of fingerprint. But, judging from the actual values, the difference of 0x4xxxxxxx might be just a leftover of wastes by BIOS programmers.
I don't mind any other way, but a sane cleanup would be appreciated.
thanks,
Takashi
Something like below?
remove all 0x4xxxxxxx from pin quirk table rewrite the pin_config_match() - first, compare all pins in a quirk table with the corresponding pin on the machine, if all pins get a matching, - second, compare all pins on the machine with the corresponding pin in the quirk table if the pin is non-0x4xxxxxxx, it needs match a corresponding pin in the quirk table, otherwise, it return false if the pin is 0x4xxxxxxx, the corresponding pin in the quirk table is 0x4xxxxxxxx as well, it matches; if the corresponding pin in the quirk table is non-0x4xxxxxxx, it return false if the pin is 0x4xxxxxxx, and can't find the corresponding pin in the quirk table, it matches.
Yes, something like that. But I think the first loop can be reduced.
If the first loop is removed, there is some situation the second one can't handle.
e.g.
a quirk table has: {0x12, 0x9xxxxxxx}, {0x14, 0x9xxxxxxx}, {0x21, 0x02xxxxxx}
while a machine only has {0x12, 0x9xxxxxxx}, {0x21, 0x02xxxxxx} and the NID 0x14 on the machine is a [Vendor Defined Widget] instead of a [pin complex].
Hm, OK, then it's a problem. Does it happen actually -- i.e. the same codec ID / revision, but containing have different widget types?
Takashi
In practice, I have never seen this situation before. I will remove the first loop and send a patch to review.
Thanks, Hui.
In this situation, only the first loop can detect they are not matching.