[ubuntu-x] Status of kernel X drivers

[Timo Aaltonen]

On Thu, 18 Feb 2010, Christopher James Halse Rogers wrote:

> On Wed, 2010-02-17 at 18:31 -0800, Bryce Harrington wrote:
>>> 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.

Why not? Aren't the fixes coming in .34 going to depend on the ABI bump, 
meaning that backporting would be harder? (and the same for the ddx)

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

2.4.18 has other fixes in it, so better to just revert the offending 
commit with a patch, and then decide if the ABI bump is worth it. Less 
work than pulling a number of patches on top of 2.4.17.

-- 
Timo Aaltonen
Systems Specialist
IT Services, Aalto University School of Science and Technology