Re: Future of the HDA driver

[David Henningsson <david.henningsson@canonical.com>]

On 10/03/2011 02:27 PM, Takashi Iwai wrote:
> At Mon, 03 Oct 2011 14:01:00 +0200,
> David Henningsson wrote:
>>
>> Hi Takashi etc,
>>
>> 1) I think it would make sense to have a designated time and room for a
>> "future of HDA" discussion in Prague. We could e g discuss input jacks
>> as kcontrols, and exposing routing to user space, as IIRC Mark Brown was
>> suggestion earlier. What do you think?
>
> Sure, we can hold a meeting spontaneously, as this would be for
> smaller group.  The sound BoF isn't exactly scheduled at all yet.
> I don't know how many guys will be there, so I thought it can be
> managed spontaneously by announcing on the message board there or so.

Sorting something out on-site will probably work as well, but I was just 
thinking that a pre-scheduled meeting is less likely to be forgotten or 
missed.

>> 2) With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the
>> door, I might have some time to contribute to the HDA driver...at least
>> if not a lot of urgent stuff comes up, and up to the 3.2 merge window or
>> so. (Any idea how far away that would be?) Do you think it would make
>> sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move
>> snd_hda_parse_pin_defcfg there, then add more functions as discovered to
>> be useful to more than one autoparser?
>
> The merge window for 3.2 is almost closed now, as 3.1 will come out
> today or tomorrow, I suppose.  Such a big change as you suggested in
> the above is a 3.3-material, I suppose.

Oh, I always seem to have bad timing :-(

But maybe I can make a 3.2 patch today or tomorrow to make naming of the 
input jacks a little more consistent, right now it's a little different 
between Realtek and Sigmatel/IDT parsers, e g.

> The unification of parsers is a longterm goal.  My plan is to reduce
> the rest of Realtek-quirk codes as much as possible in 3.3, try to
> clean up / implement the auto-parser for AD codecs, and slowly
> starting to the unified parser by moving the pieces to the core
> hd-audio code from codec-specific codes.

Hmm, maybe better to move things to a more generic auto-parser first, 
then the AD auto-parser could be more easily implemented. But I trust 
your judgement on the matter :-)

>> 3) One thing that has been annoyed me lately is the moving of hp out or
>> speaker out to line out, which IMO leads to somewhat messy code. Seen in
>> retrospect of course, don't you think it would make more sense to do let
>> line_out_pins be "line out" only, and add one more variable primary_out
>> that would be initialized as:
>>
>> primary_out_pins = line_outs ?&line_out_pins : (speaker_outs ?
>> &speaker_out_pins : (hp_outs ?&hp_out_pins : NULL))
>>
>> ..and then you could do something like:
>>
>> #define hp_is_primary_out(_auto) ((_auto)->primary_out_pins ==
>> &(_auto)->hp_out_pins)
>>
>> Redoing that will probably require careful reading to avoid regressions
>> though...
>
> Yeah, the current code is still messy although you cleaned up a lot.
> This needs revisited.

Heh, thanks for the credit, although my contributions are fairly small 
compared to yours :-)

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic