Merging DRI changes

[Alan Hourihane]

On Wed, 2007-06-13 at 18:48 -0400, 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.
> 
> I've been trying to understand the change better in order to try to
> come up with a backwards compatible way to do the same.  I think I've
> found a way to let the DDX driver tell libdri not to map the
> framebuffer and then do it itself.  The problem is that Alans patch
> also changes the DRI driver side of things to not map the front buffer
> in the loader but in the driver code, based on extra info from the DDX
> device private.
> 
> A compromise that will leave the DDX device private untouched is still
> require the framebuffer info (handle and size etc) through
> DRIGetDeviceInfo, but to not map the front buffer in the loader.
> Instead we just pass the handle and size into the DRI driver (as we do
> now), and the driver can then do the drmMap().  However, at this point
> I'm wondering what the intention of the patch is and if my suggested
> change somehow conflicts with that... help?

Kristian,

What you are suggesting sounds fine, but do you have patches to back up
the suggested compromise so I can double check ??

Thanks,

Alan.