[ubuntu-x] Status of kernel X drivers

Christopher James Halse Rogers raof at ubuntu.com
Thu Feb 18 23:52:51 UTC 2010


On Thu, 2010-02-18 at 15:17 -0800, Bryce Harrington wrote:
> On Fri, Feb 19, 2010 at 09:30:07AM +1100, Christopher James Halse Rogers wrote:
> > > I'd agree.  Plus it'll be easier to explain "we're carrying 2.4.18 minus
> > > patch foo".
> > > 
> > > Which is the commit(s) that needs reverted?
> > 
> > libdrm would need b496c63143e9a4ca02011582329bce2df99d9b7c and I think
> > also 88e8a8bbaf026aa10225880001ab7ca1c392168a reverted.
> 
> Wow, that first one is definitely a pretty significant api bump!
> 
> > If we're comfortable with pulling from the nouveau kernel tree[1] for
> > linux-backports-modules-nouveau, then going over the API bump would
> > indeed make cherry-picking and backporting fixes easier.  The API bump
> > hasn't made it out of that tree yet, as far as I'm aware.
> 
> Hrm, that kind of sucks.  But it does seem like digesting the change now
> would be easier than getting painted into a corner and have to pull it
> in post-release or something messy like that.
> 
> However, maybe it'd make sense to let the kernel drm 2.6.33 backporting
> stuff get settled out first?  So put in libdrm 2.4.18 without these two
> patches for alpha-3 so we'll have the fixes for testers, and then after
> a3 is out do the API update?

That would be fine.  It would require a DDX update, as there have been
more #define renames in libdrm since the snapshot we currently have was
cut, but this is only a build-time requirement, not a runtime problem.

We need a new upload of the DDX anyway, to fix the
linux-backports-modules-nouveau depends (which currently point to
linux-backports-modules-nouveau-2.6.32-12-generic), and possibly work
out where the initramfs hook goes.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20100219/2c556a2e/attachment.sig>


More information about the kernel-team mailing list