Status of kernel X drivers

[Steve Conklin]

On 02/17/2010 07:50 PM, Bryce Harrington wrote:
> [Forwarding to ubuntu-x@ apw's summary of some discussions we've been
> having.]
> 
> We have been chatting on and off in various forums about the state of
> the X drivers in the kernel, and it seemed time to get that discussion
> out onto the lists.
> 
> The main question is really: "Are the drivers in v2.6.32 going to be
> supportable for the LTS?".  This has been triggered by a strong upstream
> response of "That sounds like something we already fixed in 2.6.33, use
> that instead." to bugs we find in v2.6.32, this has been across all the
> graphics drivers.
> 
> There seem to be a number of options here:
> 
> Option 1 -- stick with v2.6.32: taking stable updates, backporting fixes
> and hardware enablement on a individually.  Using blacklisting where
> appropriate to alieviate symptoms,
> 
> Option 2 -- backport v2.6.33 drm: pulling back the v2.6.33 wholesale
> as that is where the developers are working, and
> 
> Option 3 -- produce an LBM backport for drm: pulling back updates for
> drm wholesale for opt-in use; effectivly in combination with #1.
> 
> Each of these have their own issues, and here I am trying to summarise
> the collective wisdom on these.
> 
> Option 1: here we have the advantage that there is work ongoing in the
> -stable team pulling back and validating fixes for this release, this is
> expected to continue for the long term as v2.6.32 has been announced as
> long term support.  This most closely fits the LTS model but is likely
> to have issues for cards at release which will need testing and
> managing.
> 
> Option 2: although we may have less issues at the outset, we are
> inevitably going to end up with the same issue that 2.6.33 is no longer
> interesting and 2.6.34 is where development is going on; we end up at
> (1) before long.  This is also high risk as we expose all users to this
> new code whether they would have a reasonable experience currently.
> 
> Option 3: here we have the work of trying to maintain the v2.6.32
> versions of the drivers, but can optionally defer backporting invasive
> changes by pushing the affected users to the backport.  We do however
> end up needing the X userspace to handle the DRM skew between the main
> kernel and the backport.
> 
> Certainly for me option 3 seems the most appropriate here.  We work the
> kernel in our normal process, we maintain no major skew in that kernel
> providing a low-risk base.  The backports provides the safety valve for
> the more invasive fixes and hardware enablement.  We backport what is
> sensible and safe, and where it is simply not practicle it goes into the
> LBM module.
> 
> This however does place some effort on the X-team, and we would like to
> start discussion on whether this seems sensible and maintainable from
> the X side.  For this to work, we would likely need to have X-server
> support for both the v2.6.32 drm stack and the v2.6.33 drm (and possibly
> later) stack.  I have heard that it _may_ be possible to serve both of
> these kernel stacks from the same userspace?  Does the X-team think that
> the current userspace bits are likely to be able to handle this level of
> skew?  Or if it is not do we think its practicle to try and handle it
> this way?  As I understand things we will have some v2.6.33 support
> required for the current Nouveau plans so we may have to do this work
> anyhow?
> 
> Anyhow I put this out there to start discussion.
> 
> Comments?  Ideas?  Feedback?
> 
> -apw
> 
> 
> ----- End forwarded message -----
> 

There was an interesting discussion on #dri-devel about this, with Dave Airlie
and others participating. Dave said that upstream development for .33 has been
focused on stability, and this is supported by looking at the patches I have
seen coming along in both radeon and intel drivers.

What was put forward as a possible approach was to do the following:

Backport the entire drm stack from .33 to Lucid. This gains us all the features
we want and brings us very close to where upstream is working. Future
backporting of fixes will be much easier, and being as far forward as we can be
will serve us best in the long time scale of the LTS release. It also gives us
all the major changes from the intel driver that are making backports of
individual features so difficult.

After release and if needed, create a lbm package to deliver .34 or .35 or
whatever we might need from future releases. If/when the upstream driver
developers stop concentrating on .33, we can maintain our main kernel with only
critical updates and backport the latest drivers for our lbm. Also, Dave Airlie
pointed out that as we move through post-Lucid releases, we will include .34+ in
these and get a sanity check of driver stability, etc before we make a decision
whether to pull them back into the Lucid lbm.

Having the lbm would also provide a good testing mechanism for xorg-edgers and
other people interested in testing the latest drivers.

With support from the X side, I think that this is a good solution.

Steve