On 10/29/07, Michel Dänzer <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-10-26 at 10:59 -0700, Jesse Barnes wrote:
> >
> > diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
> > index 707e398..25eaccc 100644
> > --- a/src/glx/x11/glxcmds.c
> > +++ b/src/glx/x11/glxcmds.c
> > @@ -2919,8 +2928,10 @@ int __glXGetInternalVersion(void)
> > * any DRI driver built to any previous version.
> > * 20060314 - Added support for GLX_MESA_copy_sub_buffer.
> > * 20070105 - Added support for damage reporting.
> > + * 20070925 - Added support for per-drawable getMSC callbacks, which
> > + * allows the core to support vblank events on multiple
> > pipes.
> > */
> > - return 20070105;
> > + return 20070925;
> > }
>
> So is this still necessary/useful?
No, and I should probably remove the api_version argument from the
CreateNewScreen entry point now that the DRI driver allocates storage
for the extension structs. The issue used to be that the DRI driver
didn't know which version of the DRI interface the loader was compiled
against and as such couldn't fill out fields appended to the struct
that the loader didn't know about.
This is no longer an issue, now that the driver returns structs of
function pointers allocated by the driver, so we should be able to
drop this argument. The core GLX objects (Screen, Drawable and
Context) are still allocated the old way, and it's one of the last
thing I'm thinking about changing in the DRI interface. Instead of
the loader providing a struct of function pointers to fill out we
could do something like this:
struct __DRIscreenInterfaceRec {
void (*destroyScreen)(__DRIscreen *screen);
...
};
struct __DRIscreenRec {
const __DRIscreenInterface *interface;
void *private;
};
and createNewScreen will return a __DRIscreenRec allocated by the
driver, where private is for the loader to use to point back to its
screen private. This will let us extend the core GLX objects too,
without the driver worrying about how many of the function pointer
fields the loader knows about. And we don't carry the same set of
function pointers around in every __DRIdrawable.
Anyway, I dunno, seems like a lot of churn for a small detail - sorry
for hijacking the thread, just saw an excuse to get this out :)
Kristian
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
