[ubuntu-x] Status of kernel X drivers

[Christopher James Halse Rogers]

On Wed, 2010-02-17 at 18:31 -0800, Bryce Harrington wrote:
> 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.
> 
As far as nouveau goes, this is pretty obviously the best solution; we
won't be supporting nouveau except via the lbm packages, so there's no
real packaging overhead.  Also, if we wanted to ship a kernel component
newer than that found in 2.6.33 we'd need to deal with the API bump that
has been threatened for ages an has now been made.  This would be
difficult, but not impossible, to deal with.  At this, post
feature-freeze stage, I don't think it's worth the effort.

I'd suggest that we stick with our current libdrm < 2.4.18, lbm-nouveau,
and xserver-xorg-video-nouveau stack, and cherry pick & backport
whatever fixes we want to grab.  In which case, as long as there's a
2.6.33 drm in lbm, the nouveau stack is happy.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-x/attachments/20100218/213a56b2/attachment.pgp