Status of kernel X drivers

[Andy Whitcroft]

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