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

[Takashi Iwai]

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.
> JOEY: YES.
> >
> >> 4. Then If I plugged in the headphone, the headphone doesn't work. It
> >> only works when I write
> >> (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_HP).
> > 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
> >> (codec,0x0F,0,AC_VERB_SET_PIN_WIDGET_CONTROL,PIN_OUT), the
> >> 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