Nouveau information and proposed plan

[Luis R. Rodriguez]

On Tue, Dec 1, 2009 at 6:43 AM, Andy Whitcroft <apw at canonical.com> wrote:
> On Mon, Nov 30, 2009 at 06:57:58PM -0600, Steve Conklin wrote:
>> This email summarizes a discussion that took place on #ubuntu-x IRC, and
>> the tentative plan that was arrived at. The IRC discussion is attached
>> for reference.
>>
>> First, there was a discussion of what is required in order to bring
>> Nouveau into our kernel. Nouveau brings in the entire drm-next tree,
>> which looks like it amounts to over 500 patches right now. This
>> presents a major issue for the kernel team, in how to manage that.
>>
>> Looking at the Fedora 12 patch set, there is a 2.9M drm-next patch.
>>
>> Assuming resolution of that issue [*], here's a tentative plan for
>> proceeding with Nouveau:
>>
>> * We pull Nouveau and the required drm changes into karmic ASAP
>> * We invest in heavy testing at alpha 1 and alpha 2, and give ourselves the chance to make an assessment after A1 whether to continue.
>> * We also decide at that point whether to rebase to a more recent nouveau or to freeze and take selected patches through the release.
>>
>> It is a bit of a tight schedule to get this into A1, since freeze is in one week.
>>
>> There was also a discussion of risks vs. benefits of going to Nouveau, see the attached log.
>>
>> [*] I defer to Andy and Tim. Backporting the entire drm-next
>> tree seems risky to me. I'd like some discussion - perhaps at
>> tomorrow's kernel team meeting.
>
> Ok.  A few comments.  The first is that at 2.9MB the drm-next update
> is just too big to be safe for general consumption, the risk to
> other drm users such as i915 and ATI radeon would be high, are we are
> meant to be more risk averse than normal for Lucid.  We likely have
> a couple of options.  The first might be to rename the updated drm ->
> drm-next.  The simpler and likely sanest approach would be to have a
> linux-backports-modules-nouveau which contains the updated drm stack and
> nouveau driver.

I'm interested in seeing more compat code being shared and stuffed
together to avoid re-inventing the wheel. We may soon backport
bluetooth for example and share a compat.ko for both bluetooth and
802.11. I know nothing about video though but do wonder if anything
from this same compat.ko could be useful to a possible video-backport
effort. So alsa had its own backport package, do the video guys do any
backports or would this have to be done from scratch?

>  Jockey and the installer should be able to bridge the
> gap there.

What if linux-next was just made available as an optional kernel for
users who wanted to test it? This would not in any way resolve the
userspace option though.

  Luis