New jack detection interface for HDA in kernel 3.3 - can we backport it?

David Henningsson david.henningsson at canonical.com
Mon Nov 14 08:12:03 UTC 2011


On 11/14/2011 09:04 AM, Stefan Bader wrote:
> On 11.11.2011 22:08, Leann Ogasawara wrote:
>> On Thu, 2011-11-10 at 11:04 +0100, David Henningsson wrote:
>>> Hi,
>>>
>>> Have a look at the test/hda-jack branch as proposed by Takashi here [1].
>>> While that branch is not ready for merging yet, something similar is
>>> very likely to land in 3.3. My question is if those six patches would be
>>> possible to backport into the Precise kernel - of course once they are
>>> tested enough to make it into Takashi's main branch?
>>
>> The changes look fairly substantial so we really have to take into
>> consideration the risk vs. reward factor here.  We obviously want to
>> avoid regressing working hardware.  And I'd also be concerned about the
>> overall maintenance burden.  It's hard to say how much collision we'll
>> see as we continue to pull in stable updates through the support cycle
>> of the LTS release.
>>
>> However, given the fact I do consider you to be one of our audio
>> experts, I'd be inclined to take this and let it bake.  Since we are in
>> the early phases of the Precise dev cycle, we can evaluate any issues
>> that may arise and back the patches out should they prove to be too
>> problematic.
>>
>> But this is just my initial thoughts.  I'd like to hear feedback from
>> others as well.
>>
>
> Along quite similar lines. We had a brief discussion of this on irc, too. And it
> sounded like David expects quite a bit of benefit there without greater fallout.
> So it seems to take them in early to verify this assumption would be a good plan.
> Also I was wondering whether the maintenance might be better off than it first
> sounds because if upstream changes in 3.3, then any stable quirks in that area
> would be against the new scheme. Though this is mostly speculation.

Thanks to both of you for your opinions. Well, for me, what we lose 
(maintenance wise) on the kernel side we win on the PulseAudio side. Add 
to that, that the new jack detection interface covers many more jacks, I 
consider it a clear win.

But let's delay the actual push to these patches have been tested a 
little more, they might not be stable enough yet (and we have no 
userspace using them yet anyway). I just needed a hint of the likely 
decision to plan my work for this week.

>>> Brief motivation for backporting: They contain a new implementation and
>>> a new kernel interface for jack detection, as well as adding more jacks
>>> (i e fixing it up for a lot of users!). Merging it would make it easier
>>> for us to stay in sync with PulseAudio's upstream as well, as PA won't
>>> merge my existing jack detection stuff now that there's a new interface
>>> to become available soon. We can also drop the udev patch that upstream
>>> wouldn't merge for the same reason.
>>
>> If we do pull in the above kernel patches I assume we will need to pick
>> up some additional pulse audio patches as well?  If so, I assume you'll
>> make sure this happens?

Certainly.

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




More information about the kernel-team mailing list