[alsa-devel] [PATCH v2] Introduce config for intel dg45id board

[Takashi Iwai]

At Tue, 08 Dec 2009 21:12:27 +0100,
Alexey Fisher wrote:
> 
> Am Dienstag, den 08.12.2009, 17:39 +0100 schrieb Takashi Iwai: 
> > At Tue, 08 Dec 2009 17:30:18 +0100,
> > Alexey Fisher wrote:
> > > 
> > > Am Dienstag, den 08.12.2009, 14:15 +0100 schrieb Takashi Iwai:
> > > > At Tue, 08 Dec 2009 14:02:43 +0100,
> > > > Alexey Fisher wrote:
> > > > > 
> > > > > Am Dienstag, den 08.12.2009, 12:04 +0100 schrieb Takashi Iwai:
> > > > > > At Sun,  6 Dec 2009 11:29:13 +0100,
> > > > > > Alexey Fisher wrote:
> > > > > > > 
> > > > > > > This patch introduce pin config and some workarounds for dg45id board.
> > > > > > > Currently tested Mic + Surround 7.1 on rear panel, and Mic + HP on front panel.
> > > > > > > SPDIF front and SPDIF rear are untested.
> > > > > > > Both Mics provide VREF_80 (4,05 V) in mic mode and no VREF in line-in mode.
> > > > > > > 
> > > > > > > Signed-off-by: Alexey Fisher <bug-track at fisher-privat.net>
> > > > > > 
> > > > > > Thanks for the patch.
> > > > > > 
> > > > > > But, I still don't see the reason for so many init verbs, especially
> > > > > > doing static routings.  Can't be they connected properly by the
> > > > > > parser?  If so, it's the parser to be fixed, not a quirky init table.
> > > > > 
> > > > > Ok. I prefer to have the part with mixer. The driver currently can't
> > > > > handle this.
> > > > 
> > > > What do you mean exactly with "mixer"?
> > > > 
> > > > > It seems to make some problem with front HP. By default All
> > > > > mixer inputs use 0x0a (Front HP out), in this situation i get hi freq
> > > > > noise on 0x0a. So or driver should learn to work with mixer or...?
> > > > 
> > > > Not sure what you are talking about here...
> > > 
> > > I talking about widget like this:
> > > 
> > > Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
> > >   Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
> > >   Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80
> > > 0x80]
> > >   Connection: 5
> > >      0x18 0x19 0x1a 0x1b 0x1d
> > > 
> > > this is an example from my laptop. Normally this widget connected to the
> > > audio selector like this:
> > > 
> > > Node 0x23 [Audio Selector] wcaps 0x300101: Stereo
> > >   Connection: 7
> > >      0x18 0x19 0x1a 0x1b 0x1d 0x12* 0x0b
> > > 
> > > ALSA will list only attached to "Audio Selector" "Mic" or "Line in"
> > > pins, not "Audio mixer". ALSA do not give control for audio mixer too.
> > 
> > Just because STAC/IDT codecs have no mixer widget.  It's a hardware
> > issue.
> 
> i talking about "IDT 92HD73E1X5" wich _has_ mixer widget. I use it on
> windows and i can use it on linux (directly, by controlling it with
> hda-verb). So this is not hardware issue. Here is the part of codecdump
> from IDT 92HD73E1X5:
> 
> Node 0x1d [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
>   Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
>   Amp-In vals:  [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97
> 0x97]
>   Connection: 5
>      0x28 0x29 0x2a 0x2b 0x12

Ah, yes, this codec has a mixer.  But, Windows never uses the analog
mixer.  They do that all in the software side.

And, the current IDT/STAC parser doesn't support it too, because
otherwise it makes the power-management more complex.


> > > > > > And, your machine has really no headphone detection?  I mean, not
> > > > > > about your taste but it's not physically doable?
> > > > > 
> > > > > HP detection working on rear green (0x0d), not on front green (0x0a).
> > > > > May be there is something wrong with connector. Anyway, it working fine
> > > > > under M$. May be we should provide UI control for this (to make user
> > > > > completely confused:)? 
> > > > 
> > > > If Windows driver can detect the front HP jack, it means the
> > > > connection is alive.  You can try hda-verb to check whether the
> > > > pin-detection works, independently from the driver setup.
> > > 
> > > Pin detection working only on rear panel, on front panel it do not
> > > working and on windows and on linux. Probably broken front panel jack...
> > > I assume windwos use different logic.
> > 
> > OK, then it's likely a typical problem of the cabling and the case model.
> > In many cases, an AC97-style case is connected to a HD-audio board.
> > 
> > > linux logic: if no hp, play sound to speaker and mute hp. if hp detected
> > > - unmute hp and mute speaker.
> > > winodws logic: if no hp detected play to hp and to speaker, if hp
> > > detected - mute speaker and continue play to hp.
> > > 
> > > I think, if ALSA will behave in same way it will need less hp quirks.
> > 
> > Yes, that's how no_jd model works.
> > 
> > But, keeping the headphone output even with unplugged state means you
> > are wasting unneeded power.  The driver powers down the circuit
> > appropriately if a pin isn't being used.  That's why the headphone
> > detection is implemented as default.
> > 
> > And, whether the HP detection works or not doesn't depend on the
> > mobo.  It's rather the connection.  So, giving the fixed "no-jd"
> > option for a certain PCI SSID is basically wrong.  Someone else might
> > have a same mobo but with a right case with the front-panel jack
> > detection.
> > 
> > That is, it's fine to create a new quirk model, but assigning
> > statically to that workaround isn't always acceptable.
> 
> Ok, i get the point. But no-jd should be provided as "Jack Detect Switch". 
> I know... i tolking about work :)... probably i'll try to do this. But i think it make sense. 

Why it must be a mixer switch?  It's obviously a system configuration.

When you set up your car and choose a Diesel or Gas motor, would you
like to change it with a gear?


Takashi