Merging DRI changes

[Jerome Glisse]

On 6/16/07, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On 6/14/07, Keith Whitwell <keith at tungstengraphics.com> wrote:
> > Kristian Høgsberg wrote:
> > > Hi,
> > >
> > > I've finished the changes to the DRI interface that I've been talking
> > > about for a while (see #5714). Ian had a look at the DRI driver side
> > > of things, and ACK'ed those changes.  I've done the X server changes
> > > now plus a couple of GLX module cleanups, and I think it's all ready
> > > to push:
> > >
> > >   http://gitweb.freedesktop.org/?p=users/krh/mesa.git;a=shortlog;h=dri2 and
> > >   http://gitweb.freedesktop.org/?p=users/krh/xserver.git;a=shortlog;h=dri2
> > >
> > > One thing that's still missing is Alan H's changes to how DRI/DDX maps
> > > the front buffer.  While the changes above break the DRI interface,
> > > they only require an X server and a Mesa update. Alans patches change
> > > the device private shared between the DDX and DRI driver and thus
> > > requires updating every DRI capable DDX driver in a non-compatible
> > > way.
> >
> > Kristian,
> >
> > Just letting you know Alan's on holidays this week, back on Monday.
>
> Ah, thanks.  I was talking to Dave about it in IRC and it sounds like
> we can let the DDX driver add the front buffer map and let the DRI
> driver set it up without breaking the shared private struct.  I've
> attached three patches (on top of my dri2 work) to illustrate the
> idea.  What's missing is the i810 specific setup in mesa and a
> mechanism to indicate whether or not dri_util.c should map the buffer
> or if the DRI driver will do that.  But that's all behind the DRI
> interface, so it's not a big deal.
>
> I'm not sure why we're doing this though.  It looks like things are
> mostly working as it is, it's just not very elegant.  And if we're
> about to shake things up with DRM memory manager enabled DDX and DRI
> drivers, do we want to add a hack like this?
>
> Kristian

My feeling is that i would love to avoid hack and take advantage of
undergoing change to fix API in sane way btw all component involved.
Maybe we should accept to break backward compat at a point in order
to properly and cleanly change all this. But as i can't devote time to
this is just my personnal view.

best,
Jerome Glisse