[ubuntu-x] Status of kernel X drivers

Bryce Harrington bryce at canonical.com
Thu Feb 18 01:50:33 GMT 2010

[Forwarding to ubuntu-x@ apw's summary of some discussions we've been

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

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 I put this out there to start discussion.

Comments?  Ideas?  Feedback?


----- End forwarded message -----

More information about the Ubuntu-x mailing list