From: David Henningsson <david.henningsson@canonical.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>
Subject: Re: [RFC PATCH] HDA: Generic input jack handling
Date: Fri, 07 Oct 2011 14:46:07 +0200 [thread overview]
Message-ID: <4E8EF48F.4000707@canonical.com> (raw)
In-Reply-To: <s5hfwj50zsq.wl%tiwai@suse.de>
On 10/07/2011 02:08 PM, Takashi Iwai wrote:
> At Fri, 07 Oct 2011 13:49:46 +0200,
> David Henningsson wrote:
>>
>> So, this is what I had in mind for 3.2. Assuming positive feedback from
>> Takashi I'll go ahead and make a real patch out of this, and to clean up
>> the Realtek implementation, as well as probably add this method for more
>> codecs.
>>
>> Thoughts:
>>
>> 1) The unsol event tags vary wildly between different vendors. How about
>> standardising that as well?
>
> Generalization is good. But tags aren't always constant. It'd be
> better to assign each tag dynamically like in patch_sigmatel.c.
> The reason is that you'd need to know the pin NID from the unsol
> event, so the tag has to be unique even for the same purpose. E.g. if
> a machine has two headphones, both are the same type but they should
> issue unsol events with different tags.
One would think that this is an area where it shouldn't differ between
vendors (after all, they need to do the same things, so this is just
different implementations), but we can clean that up later, and when
that is done we could consider standardising on having the nid as the
unsol tag value.
Anyway, as the patch below stands, sigmatel would call the function with
unsol_tags->unsol_tag = 0, and then enable the jack itself.
Did you think the patch looked good otherwise?
>> 2) If alc_init_jacks would call the new method, that might regress
>> model-based (non auto) parsers. Is that a big deal these days?
>
> I don't think so. And most of all model-based entries will vanish in
> 3.3. In 3.2, already a half of realtek quirks are gone.
Ok.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
next prev parent reply other threads:[~2011-10-07 12:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-07 11:49 [RFC PATCH] HDA: Generic input jack handling David Henningsson
2011-10-07 11:52 ` Mark Brown
2011-10-07 12:08 ` Takashi Iwai
2011-10-07 12:46 ` David Henningsson [this message]
2011-10-07 13:03 ` Takashi Iwai
2011-10-07 15:11 ` David Henningsson
2011-10-07 15:27 ` Takashi Iwai
2011-10-07 16:04 ` David Henningsson
2011-10-08 7:11 ` Takashi Iwai
2011-10-08 7:29 ` Raymond Yau
2011-10-09 8:38 ` David Henningsson
2011-10-09 10:32 ` Takashi Iwai
2011-10-09 11:14 ` David Henningsson
2011-10-13 6:40 ` Takashi Iwai
2011-10-18 13:13 ` David Henningsson
2011-10-18 13:23 ` Takashi Iwai
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=4E8EF48F.4000707@canonical.com \
--to=david.henningsson@canonical.com \
--cc=alsa-devel@alsa-project.org \
--cc=tiwai@suse.de \
/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.