[git pull] drm fixes

[Jesse Barnes]

On Fri, 25 Mar 2011 10:01:14 -0400
Jerome Glisse <j.glisse at gmail.com> wrote:

> On Fri, Mar 25, 2011 at 6:25 AM, Ben Skeggs <skeggsb at gmail.com> wrote:
> > Oh, I wish this were actually the case.  The last time we attempted such a thing we were blasted by Linus.  It does make me wonder at why we're even bothering being in staging.
> >
> > This is where the binary drivers have a huge advantage, they package all the pieces of their driver together and can modify things as necessary.
> >
> > Part of me does think such an approach with the open source graphics drivers would be better.  The current model doesn't really fit too well in my opinion.  Though, admittedly, there's different problems to going other ways.
> >
> > Ben.
> 
> Well i think being able to evolve the API would help a lot, it should
> still be possible to keep supporting old API over a year or so. But my
> feeling is some of the current API for some of the device, needs heavy
> lifting if we ever want to improve things.

Going back to the old model of a separate drm repo would create more
problems than it solves, IMO.

One thing I think Linus has been fairly consistent about is that making
things easy for users (well at least power users who build their own
kernels) is important.  That means ABIs need to be stable so that their
existing userspace continues to work even after a kernel upgrade.

If we went back to the old, out of tree model, we might be able to
break things more easily (i.e. require lockstep upgrades of kernel &
userspace when we change things, hopefully for a good reason), but I
think end users would end up suffering.  They'd have to rely on their
distro to pick up such changes and make sure dependencies were met and
that upgrades/downgrades worked properly across the pre-packaged
kernels that they made available.

One of the main reasons we moved in-tree was to make sure our bits got
into the hands of users more quickly, and to make life easier for the
various downstream distros, not all of which have deep expertise in the
graphics stack.

Fortunately, neither of the issues that started this thread, the
suspend/resume regression in i915 and the vblank ioctl enhancement, are
problems in this respect.  The former is just a bug (though definitely
not one that should have made it to Linus's tree) and the latter does
preserve compatibility and fix a major issue, so isn't really a problem
imo.

But in the general sense, I think we just have to bite the bullet, take
our time with ABI additions and changes so as to preserve compatibility
for a long time (I think we've been doing well with this on the Intel
side at least; we add feature flags every time we change something, and
make sure userspace is forward and backward compatible).  This is more
work for us, but I think it benefits the user in the end.  And it could
be worse, at least we're not still dealing with memory layout
compatibility between the DRM, fbdev, DDX and DRI drivers anymore!

-- 
Jesse Barnes, Intel Open Source Technology Center