[alsa-devel] Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series

joey.jiaojg joey.jiaojg at gmail.com
Wed Feb 15 15:45:27 CET 2012

I think the only question below is about the automute, right?
Then I did another test by modifying like below (so the result is same 
as sending any hda-verb cmd) -- The result is the auto-mute works too:
if (present) {
                 snd_hda_codec_write_cache(codec, 0x01, 0,
                                           AC_VERB_SET_GPIO_MASK, 0);
                 snd_hda_codec_write_cache(codec, 0x01, 0,
                 /*snd_hda_codec_write_cache(codec, 0x0f, 0,
                 snd_hda_codec_read(codec, 0x01, 0,
         } else {
                 snd_hda_codec_write_cache(codec, 0x01, 0,
                                           AC_VERB_SET_GPIO_MASK, 1);
                 snd_hda_codec_write_cache(codec, 0x01, 0,
                 /*snd_hda_codec_write_cache(codec, 0x0f, 0,
                 snd_hda_codec_read(codec, 0x01, 0,

On 2012年02月15日 21:21, Takashi Iwai wrote:
> At Wed, 15 Feb 2012 21:14:48 +0800,
> joey.jiaojg wrote:
>> Please check my reply below.
>> On 2012年02月15日 18:11, Takashi Iwai wrote:
>>> At Wed, 15 Feb 2012 18:06:39 +0800,
>>> joey.jiaojg wrote:
>>>> OK, the situation is 0x01 is to control GPIO0:
>>>> 1. if I write (codec,0x01,0,AC_VERB_SET_GPIO_MASK,1) only; the result is
>>>> speaker not work.
>>>> 2. if I write (codec,0x01,0,AC_VERB_SET_GPIO_DIRECTION,1) only; the
>>>> result is speaker not work.
>>> Sure, GPIO must be always set mask, direction and data all together.
>>> The question is, when you set GPIO mask/dir/data, the speaker starts
>>> playing, and if set to zero (e.g. only data), the speaker is muted?
>> JOEY: I tried set data to 0 or 1 doesn't influence. when I set mask&
>> dir to 1, speaker starts to work and to 0 speaker muted while headphone
>> works if headphone plugged in.
> There is something wrong in tests.  The direction bit controls only
> the direction, so yes, it must match with the value the hardware
> expected.  Otherwise it won't work, thus it's turned off.
>>>> 3. If I write step 1&   2 together, speaker works when I reboot.
>>> Then GPIO is likely an external amp control.
>>>> 4. Then If I plugged in the headphone, the headphone doesn't work. It
>>>> only works when I write
>>> This is normal.
>> JOEY: If I don't modify model=will. And headphone can play even without
>> set AC_VERB_SET_PIN_WIDGET_CONTROL to PIN_HP. Of course, automute
>> doesn't work as there is function implemented.
> OK, this is because of model=will strange things.
>>>> 5. From step 3&   4, it's similar for cases that I reboot with headphone
>>>> plugged in. That is, if I remove headphone, speaker doesn't work
>>>> automatically. If I write
>>>> auto-detection function works well can switch speaker/headphone
>>>> automatically.
>>> That's odd.  If you don't change from PIN_HP, doesn't the unsolicited
>>> event work?
>> JOEY: the unsolicited works from the register I read also from the
>> printk I previous added. But the audio path doesn't switch between
>> speaker and headphone. I don't know why. It can works manually if I send
>> any hda-verb command to codec, like hda-verb /dev/snd/hwC0D0 0x0F 0xF09
>> 0x0; I think perhaps there needs to be some delay. But I wait seconds
>> and it doesn't switch. Then if I run any hda-verb command, it will then
>> switch.
>> Then after I change from PIN_HP or from PIN_OUT, the automute (actually
>> audio path switch) works.
> Is the effect only with this pin?  In other words, if you change the
> pin control value of other pin, no similar effect?
>>> Another question is, when you set PIN_WIDGET_CONTROL on the speaker
>>> pin (not sure which one is) to 0x00, does it mute the speaker, too?
>> JOEY: No, it doesn't mute the speaker. To mute the speaker, I just need
>> to set 0 to dir or mask. Then audio path is to headphone.
> And you are sure that it's the right pin?  Which pin did you test?
> The pin-control doesn't always turn off the output in some cases.
> But, we'd need to be sure whether we are looking at the right one.
> thanks,
> Takashi

More information about the Alsa-devel mailing list