Re: Merging DRI changes

[Alan H. <al...@fa...>]

On Wed, 2007-06-13 at 18:48 -0400, Kristian H=C3=B8gsberg wrote:
> Hi,
>=20
> 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:
>=20
>   http://gitweb.freedesktop.org/?p=3Dusers/krh/mesa.git;a=3Dshortlog;h=3D=
dri2 and
>   http://gitweb.freedesktop.org/?p=3Dusers/krh/xserver.git;a=3Dshortlog=
;h=3Ddri2
>=20
> 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.
>=20
> 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.
>=20
> 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.