From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Suggestion: Jack nodes detection Date: Mon, 24 Nov 2008 07:58:51 +0100 Message-ID: References: <4928B240.9030905@yahoo.fr> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 0A6CD2455F for ; Mon, 24 Nov 2008 07:58:52 +0100 (CET) In-Reply-To: <4928B240.9030905@yahoo.fr> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Vincent Petry Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Sun, 23 Nov 2008 09:30:40 +0800, Vincent Petry wrote: > > Hi, > > I have noticed that from one model to another in ALC888 (maybe others as > well), the nodes for Int speakers, HP out, are not always the same. > But in the current driver model in patch_realtek.c we always hard-code > the node numbers, for example 0x14 for int speakers, 0x15 for hp out, etc. Note that this is what the preset model assumes -- the same pin configuration. > It would be good to have it this way: > 1. Add a spec attribute that contains the output nids in a given order > or a map, like this for my laptop: > alc888_acer_aspire_jack_nids = > { > {0x14, NID_INT_SPEAKER}, > {0x15, NID_HP_OUT}, > {0x18, NID_MIC_IN}, > {0x1a, NID_LINE_IN}, > {} > }; > > For another laptop, that has built-in subwoofer: > alc888_fujitsu_xa2530_jack_nids = > { > { > {0x14, NID_INT_SPEAKER}, > {0x15, NID_INT_SPEAKER}, // subwoofer, also considered as int speaker > for the jack sense muting > {0x17, NID_LINE_OUT}, // this is also side > {0x18, NID_MIC_IN}, > {0x1a, NID_LINE_IN}, > {} > }; > > > This way we could then use a function to access the NID number of each > one of them, for example get_jack_nid(..., NID_INT_SPEAKER). The mapping is nice. A similar mechanism is found in patch_sigmatel.c. But I'd suggest to avoid the name NID_*, because this sounds like a widget NID although it doesn't mean so in this case: it's the role of each pin. Thus, something like ALC_PIN_INT_SPEAKER would be more appropriate. > 2. Once this is implemented, we could add a detection routine that would > build the above map automatically, based on the spec info returned by > the codec. > > 3. Then I think we should add some special "detection" model that has no > hard-coded values that anyone could use by default, if no suitable model > def exists. Such a model can be hardcoded indeed. No need to introduce a model over a model at this point. If any better way comes in sight, we can go forward. But let's reduce the codes step by step. thanks, Takashi