In several places the DRI code is assuming that it is implementing
GLX. One example of this is __glXFindDRIScreen.
All of the context functions take (__DRInativeDisplay *dpy, int scrn)
and then call pDRIScreen = glx_find_dri_screen(dpy, scrn); to get the
screen object. The assumption here is that screens are int's, in my
case they are not.
I also have two sets of mapping going on; at the higher level it is
GLX screens and lower level it is EGL screens. There is only one
mapping function.
Another way to do this would be to create something like
struct {
__DRIscreen screen;
} GLXScreen;
The context functions would then take pointers to GLXScreen and the
find_dri_screen would take place before calling the DRI code. Only
screens have this problem, other objects are ok.
DRI calls these GLX functions:
__glXCreateContextModes
__glXCreateContextWithConfig
__glXFindDRIScreen
__glXGetDrawableInfo
__glXGetInternalVersion
__glXGetUST
__glXScrEnableExtension
__glXWindowExists
glXGetMscRateOML
It also makes calls to these XF86DRI functions:
XF86DRICreateContext
XF86DRICreateDrawable
XF86DRIDestroyDrawable
XF86DRIDestroyContext
XF86DRIQueryDirectRenderingCapable
XF86DRIOpenConnection
XF86DRIAuthConnection
XF86DRIGetClientDriverName
XF86DRIQueryVersion
XF86DRIGetDeviceInfo
XF86DRICloseConnection
XF86DRIGetDrawableInfo
Is there any simple way to sort of this out? I'd rather not build
another version of dri_util.c with slight variations just to support
EGL.
--
Jon Smirl
[EMAIL PROTECTED]
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
