Headset mic support for a Dell laptop machine
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Woodrow Shen |
Bug Description
When the headset was plugged in the Dell laptop, the mic of headset can't be detected and workable.
Codec: Realtek ALC256
Vendor Id: 0x10ec0256
Subsystem Id: 0x102806f2
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
assignee: | nobody → Woodrow Shen (woodrow-shen) |
description: | updated |
Woodrow Shen (woodrow-shen) wrote : [alsa-devel][PATCH] ALSA: hda - Add pin quirk for the headset mic jack detection on Dell laptop | #1 |
Changed in linux (Ubuntu): | |
status: | Confirmed → In Progress |
Takashi Iwai (tiwai) wrote : | #2 |
On Mon, 27 Jul 2015 12:34:31 +0200,
<email address hidden> wrote:
>
> From: Woodrow Shen <email address hidden>
>
> 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_
> is simplified by removing them. This makes headset mic works on laptop.
>
> Codec: Realtek ALC256
> Vendor Id: 0x10ec0256
> Subsystem Id: 0x102806f2
>
> BugLink: https:/
> Signed-off-by: Woodrow Shen <email address hidden>
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
> ---
> sound/pci/
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/sound/
> index d94c0e3..4ae877c 100644
> --- a/sound/
> +++ b/sound/
> @@ -5398,8 +5398,6 @@ static const struct hda_model_fixup alc269_
> {0x19, 0x411111f0}, \
> {0x1a, 0x411111f0}, \
> {0x1b, 0x411111f0}, \
> - {0x1d, 0x40700001}, \
> - {0x1e, 0x411111f0}, \
> {0x21, 0x02211020}
>
> #define ALC282_
> @@ -5556,10 +5554,19 @@ static const struct snd_hda_pin_quirk alc269_
> {0x21, 0x02211030}),
> SND_HDA_
> ALC256_
> - {0x13, 0x40000000}),
> + {0x13, 0x40000000},
> + {0x1d, 0x40700001},
> + {0x1e, 0x411111f0}),
> SND_HDA_
> ALC256_
> - {0x13, 0x411111f0}),
> + {0x13, 0x411111f0},
> + {0x1d, 0x40700001},
> + {0x1e, 0x411111f0}),
> + SND_HDA_
> + ALC256_
> + {0x13, 0x411111f0},
> + {0x1d, 0x4077992d},
> + {0x1e, 0x411111ff}),
> SND_HDA_
> {0x12, 0x90a60130},
> {0x13, 0x40000000},
> --
> 2.1.4
>
Changed in linux (Ubuntu): | |
status: | In Progress → Fix Committed |
Hui Wang (hui.wang) wrote : Re: [alsa-devel] [PATCH] ALSA: hda - Add pin quirk for the headset mic jack detection on Dell laptop | #3 |
On 07/27/2015 06:52 PM, Takashi Iwai wrote:
> On Mon, 27 Jul 2015 12:34:31 +0200,
> <email address hidden> wrote:
>> From: Woodrow Shen <email address hidden>
>>
>> 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_
>> is simplified by removing them. This makes headset mic works on laptop.
>>
>> Codec: Realtek ALC256
>> Vendor Id: 0x10ec0256
>> Subsystem Id: 0x102806f2
>>
>> BugLink: https:/
>> Signed-off-by: Woodrow Shen <email address hidden>
> 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.
diff --git a/sound/
b/sound/
index 03b7399..2639fc3 100644
--- a/sound/
+++ b/sound/
@@ -887,11 +887,38 @@ EXPORT_
static bool pin_config_
{
- for (; pins->nid; pins++) {
- u32 def_conf = snd_hda_
- if (pins->val != def_conf)
+ const struct hda_pintbl *t_pins = pins;
+ int i;
+
+ for (; t_pins->nid; t_pins++) {
+ u32 def_conf = snd_hda_
+ if (t_pins->val != def_conf)
+ return false;
+ }
+
+ for (i = 0; i < codec->
+ struct hda_pincfg *pin =
snd_array_
+ hda_nid_t nid = pin->nid;
+ u32 cfg = pin->cfg;
+ int found;
+
+ t_pins = pins;
+ found = 0;
+ for (; t_pins->nid; t_pins++) {
+ if (t_pins->nid == nid) {
+ found = 1;
+ if (...
Takashi Iwai (tiwai) wrote : | #4 |
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,
> > <email address hidden> wrote:
> >> From: Woodrow Shen <email address hidden>
> >>
> >> 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_
> >> is simplified by removing them. This makes headset mic works on laptop.
> >>
> >> Codec: Realtek ALC256
> >> Vendor Id: 0x10ec0256
> >> Subsystem Id: 0x102806f2
> >>
> >> BugLink: https:/
> >> Signed-off-by: Woodrow Shen <email address hidden>
> > 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.
thanks,
Takashi
>
>
>
>
> diff --git a/sound/
> b/sound/
> index 03b7399..2639fc3 100644
> --- a/sound/
> +++ b/sound/
> @@ -887,11 +887,38 @@ EXPORT_
> static bool pin_config_
> const struct hda_pintbl *pins)
> {
> - for (; pins->nid; pins++) {
> - u32 def_conf = snd_hda_
> - if (pins->val != def_conf)
> + const struct hda_pintbl *t_pins = pins;
> + int i;
> +
> + for (; t_pins->nid; t_pins++) {
> + u32 def_conf = snd_hda_
> + if (t_pins->val != def_conf)
> + return false;
> + }
> +
> + for (i = 0; i < codec->
> + struct hda_pincfg *pin =
> snd_array_
> + hda_nid_t nid = pin->nid;
> + ...
Hui Wang (hui.wang) wrote : | #5 |
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,
>>> <email address hidden> wrote:
>>>> From: Woodrow Shen <email address hidden>
>>>>
>>>> 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_
>>>> is simplified by removing them. This makes headset mic works on laptop.
>>>>
>>>> Codec: Realtek ALC256
>>>> Vendor Id: 0x10ec0256
>>>> Subsystem Id: 0x102806f2
>>>>
>>>> BugLink: https:/
>>>> Signed-off-by: Woodrow Shen <email address hidden>
>>> 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].
In this situation, only the first loop can detect they are not matching.
Regards,
Hui.
>
> thanks,
>
> Takashi
>
>>
>>
>>
>> diff --git a/sound/
>> b/sound/
>> index 03b7399..2639fc3 100644
>> --- a/sound/
>> +++ b/sound/
>> @@ -887,11 +887,38 @@ EXPORT_
>> static bool pin_config_
>> const struct hda_pintbl *pins)
>> {
>> - for (; pins->nid; pins++) {
>> - u32 def_conf = snd_hda_
>> - if (pins->val != def_c...
Takashi Iwai (tiwai) wrote : | #6 |
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,
> >>> <email address hidden> wrote:
> >>>> From: Woodrow Shen <email address hidden>
> >>>>
> >>>> 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_
> >>>> is simplified by removing them. This makes headset mic works on laptop.
> >>>>
> >>>> Codec: Realtek ALC256
> >>>> Vendor Id: 0x10ec0256
> >>>> Subsystem Id: 0x102806f2
> >>>>
> >>>> BugLink: https:/
> >>>> Signed-off-by: Woodrow Shen <email address hidden>
> >>> 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 this situation, only the first loop can detect they are not matching.
>
>
> Regards,
> Hui.
> >
> > thanks,
> >
> > Takashi
> >
> >>
> >>
> >>
> >> diff --git a/sound/
> >> b/sound/
> >> index 03b7399..2639fc3 100644
> >> --- a/sound/
> >> +++ b/sound/
Hui Wang (hui.wang) wrote : | #7 |
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,
>>>>> <email address hidden> wrote:
>>>>>> From: Woodrow Shen <email address hidden>
>>>>>>
>>>>>> 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_
>>>>>> is simplified by removing them. This makes headset mic works on laptop.
>>>>>>
>>>>>> Codec: Realtek ALC256
>>>>>> Vendor Id: 0x10ec0256
>>>>>> Subsystem Id: 0x102806f2
>>>>>>
>>>>>> BugLink: https:/
>>>>>> Signed-off-by: Woodrow Shen <email address hidden>
>>>>> 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.
>>
>>
madbiologist (me-again) wrote : | #8 |
Fixed in Ubuntu 15.04 "Vivid Vervet" and Ubuntu 14.04.3 LTS - see the "Kernel and Hardware support updates" section at https:/
Changed in linux (Ubuntu): | |
status: | Fix Committed → Fix Released |
From: Woodrow Shen <email address hidden>
The new Dell laptop with codec 256 can't detect headset mic when headset was STANDARD_ PINS can't match pin definition. Also, the macro ALC256_ STANDARD_ PINS
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_
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 pci/hda/ patch_realtek. c | 15 +++++++++++----
Signed-off-by: Woodrow Shen <email address hidden>
---
sound/
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/sound/ pci/hda/ patch_realtek. c b/sound/ pci/hda/ patch_realtek. c pci/hda/ patch_realtek. c pci/hda/ patch_realtek. c fixup_models[ ] = {
index d94c0e3..4ae877c 100644
--- a/sound/
+++ b/sound/
@@ -5398,8 +5398,6 @@ static const struct hda_model_fixup alc269_
{0x19, 0x411111f0}, \
{0x1a, 0x411111f0}, \
{0x1b, 0x411111f0}, \
- {0x1d, 0x40700001}, \
- {0x1e, 0x411111f0}, \
{0x21, 0x02211020}
#define ALC282_ STANDARD_ PINS \ pin_fixup_ tbl[] = { PIN_QUIRK( 0x10ec0256, 0x1028, "Dell", ALC255_ FIXUP_DELL1_ MIC_NO_ PRESENCE, STANDARD_ PINS, PIN_QUIRK( 0x10ec0256, 0x1028, "Dell", ALC255_ FIXUP_DELL1_ MIC_NO_ PRESENCE, STANDARD_ PINS, PIN_QUIRK( 0x10ec0256, 0x1028, "Dell", ALC255_ FIXUP_DELL1_ MIC_NO_ PRESENCE, STANDARD_ PINS, PIN_QUIRK( 0x10ec0280, 0x103c, "HP", ALC280_ FIXUP_HP_ GPIO4,
@@ -5556,10 +5554,19 @@ static const struct snd_hda_pin_quirk alc269_
{0x21, 0x02211030}),
SND_HDA_
ALC256_
- {0x13, 0x40000000}),
+ {0x13, 0x40000000},
+ {0x1d, 0x40700001},
+ {0x1e, 0x411111f0}),
SND_HDA_
ALC256_
- {0x13, 0x411111f0}),
+ {0x13, 0x411111f0},
+ {0x1d, 0x40700001},
+ {0x1e, 0x411111f0}),
+ SND_HDA_
+ ALC256_
+ {0x13, 0x411111f0},
+ {0x1d, 0x4077992d},
+ {0x1e, 0x411111ff}),
SND_HDA_
{0x12, 0x90a60130},
{0x13, 0x40000000},
--
2.1.4