Re: [PATCH] Four patches to fixup surround internal speakers on Realtek 88x

From: Takashi Iwai <tiwai@suse.de>
To: David Henningsson <david.henningsson@canonical.com>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	nusch88@gmail.com
Subject: Re: [PATCH] Four patches to fixup surround internal speakers on Realtek 88x
Date: Mon, 07 Mar 2011 11:54:58 +0100	[thread overview]
Message-ID: <s5hvczvfbel.wl%tiwai@suse.de> (raw)
In-Reply-To: <4D74B785.1060000@canonical.com>

At Mon, 07 Mar 2011 11:46:29 +0100,
David Henningsson wrote:
> 
> On 2011-03-07 10:37, Takashi Iwai wrote:
> > At Mon, 07 Mar 2011 09:22:42 +0100,
> > David Henningsson wrote:
> >>
> >> I spend last Friday together with Bartłomiej Żogała fixing up a long
> >> standing issue with Lenovo Y530, which has 4+1 internal speakers on a
> >> Realtek 888. And we all want that supported by the auto parser, don't
> >> we?
> >
> > Well, it's a bit flaky.  The current behavior assigning speakers only
> > as "Speaker" is intentional.  This is a simplification to avoid the
> > conflict with the case where both multiple line-outs and multiple
> > speakers are present.
> 
> In that case, nothing changes - this code path is not taken, since 
> line_out_type wouldn't be AUTO_PIN_SPEAKER_OUT.

Hm, I see.

> > And, in general, I don't like to get rid of "Speaker" notation.  If
> > any, we should keep "Speaker" with a channel prefix.
> 
> This is indeed tricky, and I think we've stranded on a similar issue 
> here once before.
> 
> Btw, in the case of this particular machine, the "Front" controls the 
> headphones as well, so the name is accidentally correct.

OK, then it's good to take.
Let me check these patches a bit.  Then I'll merge them.

> I've even seen a machine where a DAC controlled two out of three fronts 
> (e g headphones and line-out but not speaker, or something like that) - 
> how would you name that?

It's a difficult choice, yeah.  If I would have to choose, I'd take
"Headphone" and "Speaker", and make line-out implicit.  But this is
neither ideal solution, of course.

> Perhaps it is time to start to come up with a more reliable naming 
> scheme for 2.6.39 or 2.6.40, that would take into account the more 
> trickier combinations as well.

The time for 2.6.39 is almost closed :)
But I fully agree with a major re-design for more consistent control
names.

thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel