On Fri, 25 Mar 2011 10:01:14 -0400 Jerome Glisse <j.glisse@xxxxxxxxx> wrote: > On Fri, Mar 25, 2011 at 6:25 AM, Ben Skeggs <skeggsb@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
