All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Vincent Petry <PVince81@yahoo.fr>
Cc: alsa-devel@alsa-project.org
Subject: Re: Suggestion: Jack nodes detection
Date: Mon, 24 Nov 2008 07:58:51 +0100	[thread overview]
Message-ID: <s5hskph7gpg.wl%tiwai@suse.de> (raw)
In-Reply-To: <4928B240.9030905@yahoo.fr>

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

      reply	other threads:[~2008-11-24  6:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-23  1:30 Suggestion: Jack nodes detection Vincent Petry
2008-11-24  6:58 ` Takashi Iwai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hskph7gpg.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=PVince81@yahoo.fr \
    --cc=alsa-devel@alsa-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.