Nouveau information and proposed plan

[Christopher James Halse Rogers]

On Tue, 2009-12-01 at 14:43 +0000, Andy Whitcroft 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.  Jockey and the installer should be able to bridge the
> gap there.
What would be the cost/benefit here over the current
nouveau-kernel-source source, built with dkms?
The ones I can think of are: 

pros: 
*) Users do not need kernel headers installed
*) Fewer packaging variables; we know the exact kernel version nouveau
+drm needs to build against.

cons:
*) Update skew - the nouveau DDX doesn't handle a missing drm module
with any degree of aplomb, and it's not possible to ensure that a
linux-backport-modules-nouveau package for the currently running kernel
ABI is installed.  This is also a problem for the current
nouveau-kernel-source package, but I think it's a bit easier to ensure
that the right kernel headers get installed.

Another option would be to see what needs to be done to nouveau to make
it work on our current drm.  There didn't seem to be a *huge* diffstat
between our current drm/ttm and what nouveau uses.  I'm not wild about
this idea, though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20091202/39189b02/attachment.sig>