[ubuntu-x] Status of kernel X drivers

[Bryce Harrington]

On Wed, Feb 17, 2010 at 05:50:33PM -0800, Bryce Harrington wrote:
> 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.

This stays the most true to our original plans and thus is the least
disruptive to our current efforts.  I think this could be a good option
*IF* we can get a LOT of kernel fixes and hardware enablement from
2.6.33 backported.

> 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.

I agree the risk level is high here.  As well, there are at least a few
gotchas present in 2.6.33 that we'd need to get resolved, such as
needing the RLC firmware for r600-r700 (non-free license).  And probably
more we don't yet know about.

> 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.

This option is kind of a best-of-both-worlds options, but it's the most
complex of the three from a packaging standpoint.  Testing the various
permutations could be challenging as well.  It gives the user a lot of
power but also plenty of opportunity to shoot themselves in the foot.

A further benefit of this approach is that backporting upstream fixes
for 2.6.33 drm would be easier than if we pulled all of 2.6.33 drm in,
since it would just require updating lbm only, where SRU requirements
are simpler than for updates to the base kernel.

> 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.

I guess for this we'd need to configure things something like:

                 2.6.32           2.6.33
  Intel         -intel/KMS *     -intel/KMS
  ATI           -ati/UMS **      -ati/KMS
  Nvidia         N/A ***         -nouveau/KMS

For X components, I think as long as we have ones compatible with
2.6.33, potentially they'll be backwards compatible to 2.6.32.
But we'll need to verify that.  If not, things could get messy.
Maybe some of the other Ubuntu-X guys can chip in some of their thoughts
on this.

*   - For Intel/KMS, we probably need to blacklist all the 8xx cards.
      Some of them might work, but users could then selectively use LBM
      (2.6.33) in those cases.

**  - The kernel would need to either shut off KMS for radeon in this
      case, or blacklist the R100-R200 (and probably more) cards.

*** - In theory, we could allow users to uninstall LBM and return to
      -nv.  Honestly, though, most users will be going to -nvidia, so
      it doesn't seem like this is worth the effort it'd take.

Bryce