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@hp /home/wfg# hda-verb /dev/snd/hwC0D0 0x16 GET_PIN_SENSE 0 > nid = 0x16, verb = 0xf09, param = 0x0 > value = 0x7fffffff > root@hp /home/wfg# hda-verb /dev/snd/hwC0D0 0x16 GET_PIN_SENSE 0 > nid = 0x16, verb = 0xf09, param = 0x0 > value = 0x7fffffff > root@hp /home/wfg# hda-verb /dev/snd/hwC0D0 0x16 SET_PIN_SENSE 0 > nid = 0x16, verb = 0x709, param = 0x0 > value = 0x0 > root@hp /home/wfg# hda-verb /dev/snd/hwC0D0 0x16 GET_PIN_SENSE 0 > nid = 0x16, verb = 0xf09, param = 0x0 > value = 0xcd00 > root@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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel