[alsa-devel] [PATCH] hda: enable speaker output for Compaq 6530s/6531s

Takashi Iwai tiwai at suse.de
Wed Aug 19 10:47:45 CEST 2009


At Wed, 19 Aug 2009 16:27:52 +0800,
Wu Fengguang wrote:
> 
> On Mon, Aug 17, 2009 at 02:46:14PM +0800, Takashi Iwai wrote:
> > At Sun, 16 Aug 2009 19:01:10 +0800,
> > Wu Fengguang wrote:
> > > 
> > > On Sun, Aug 16, 2009 at 05:22:23PM +0800, Takashi Iwai wrote:
> > > > At Sun, 16 Aug 2009 16:53:17 +0800,
> > > > Wu Fengguang wrote:
> > > > > 
> > > > > There are 3 causes to the silence of Compaq 6530s' internal speaker:
> > > > > - HP pin 0x11 always return 0xffff,ffff (pin_presence=1),
> > > > >   which automutes the speaker at module loading time.
> > > > 
> > > > This is odd.  Is the sense-trigger issued before reading the pin sense?
> > > 
> > > Sorry, what do you mean?  The facts I explored are:
> > > - ad1884a_hp_automute() will be explicitly called by ad1884a_hp_init()
> > > - ad1884a_hp_unsol_event() is never called on plug events
> > > - I tried manually execute AC_VERB_SET_PIN_SENSE then read pin sense,
> > >   it takes effect on the impedance, but pin_presence still remains 1.
> > 
> > The fact that it returns only -1 sounds rather like a hardware issue.
> > Or, at least, reading a wrong place or so.
> 
> It may well be a hardware issue. But note that SET_PIN_SENSE could change
> the return value of GET_PIN_SENSE, except for the highest pin_presence bit:
> 
>         root at hp /home/wfg# hda-verb /dev/snd/hwC0D0 0x16 GET_PIN_SENSE 0            
>         nid = 0x16, verb = 0xf09, param = 0x0
>         value = 0x7fffffff
>         root at hp /home/wfg# hda-verb /dev/snd/hwC0D0 0x16 GET_PIN_SENSE 0
>         nid = 0x16, verb = 0xf09, param = 0x0
>         value = 0x7fffffff
>         root at hp /home/wfg# hda-verb /dev/snd/hwC0D0 0x16 SET_PIN_SENSE 0
>         nid = 0x16, verb = 0x709, param = 0x0
>         value = 0x0
>         root at hp /home/wfg# hda-verb /dev/snd/hwC0D0 0x16 GET_PIN_SENSE 0
>         nid = 0x16, verb = 0xf09, param = 0x0
>         value = 0xcd00
>         root at hp /home/wfg# hda-verb /dev/snd/hwC0D0 0x16 GET_PIN_SENSE 0
>         nid = 0x16, verb = 0xf09, param = 0x0
>         value = 0xcd00

Indeed.  I guess the impedance measurement is done at the trigger time.

> > > > > - HP pin 0x11 won't emit unsol events on jack plug/unplug,
> > > > >   so the speaker have no chance to be unmuted.
> > > > 
> > > > Can it be fixed with enable_msi=1 option?
> > > 
> > > Not yet, will try it.
> > > 
> > > > > - pin 0x1c must be set to PIN_OUT mode to make the speaker work
> > > > >   this is the most weird part - line-in pin 0x1c and speaker pin 0x16
> > > > >   seem to be unrelated.
> > > > 
> > > > Hm, sounds strange.
> > > 
> > > Yes. Note that the 6530s I have is a test box. Another 6531s which
> > > is bought directly from market don't have this bug.
> > > 
> > > > > Fix the problems by
> > > > > - add "Speaker" and "Headphone" mixers to allow hand tuning by user
> > > > 
> > > > It's a bit buggy because the auto-mute feature can turn on/off these
> > > > silently.  If any, these controls have to be notified at changing the
> > > > state via plugging.
> > > 
> > > OK. Are there code examples for doing this? Thank you!
> > 
> > Basically you need to call snd_ctl_notify() to control elements which
> > h/w values are changed.  In that way, the mixer app can be notified and
> > update the values appropriately.
> > 
> > However, I think adding these control unconditionally to the existing
> > model is no right solution.  The laptop model is designed for the device
> > where the HP jack detection works properly.  If the device isn't such one,
> > the model itself isn't applicable.
> > 
> > So, it's better to create either another model without jack detection,
> > or add a check for hint strings, at least.
> > In either case, you can create two controls, Headphone and Speaker,
> > which access the h/w normally without master control.  Then a master
> > control will be automatically created as vmaster.
> 
> Thanks for the tips! However I'm now wondering the value of doing this:
> it may well be an early stage hardware bug and may no longer exist in
> the market.. I'm quite content on enabling 6531s and assume the patch
> will work alike for 6530s in the market :)

Yeah, I agree.


thanks,

Takashi


More information about the Alsa-devel mailing list