[alsa-devel] Suggestion: Jack nodes detection

Takashi Iwai tiwai at suse.de
Mon Nov 24 07:58:51 CET 2008


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


More information about the Alsa-devel mailing list