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?

cheers,
Kristian

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to