The first obvious problem with a single binary is that the XFree86 build of the driver makes a number of X-protocal calls in the bootstrap process and whenever a context or a drawable is created or destroyed. The biggest offender is __driUtilCreateScreen in dri_util.c. This is the routine that does the real work of bootstrapping the driver. I updated the driCreateNewScreen interface proposed in [1] to add framebuffer, version, and DRM device handle data. The net result is that *ALL* of the XF86DRI and drm calls in __driUtilCreateScreen can be done from within libGL *BEFORE* calling into the driver.
Once that change is made, a non-backwards compatable driver binary would only have calls to XF86DRICreateDrawable, XF86DRIDestroyDrawable, XF86DRICreateContext, XF86DRIDestroyContext, and XF86DRIGetDrawableInfo. I began looing at the create / destroy context routines next.
The context related routines, it turns out, are a big, BIG problem. However, the problem is not on the client-side. It's on the server-side. The routines in libdri.a that handle these protocol requests start by looking up the visualID in the table of GLX visuals (see programs/Xserver/GL/dri/xf86dri.c, line 310). They then look-up the visual ID in the table of X visuals, and make a call into the DDX driver. Therein lies the problem. When fbconfigs are added, the interface in the DDX driver is broken. Because an fbconfig carries a LOT more data than a classic GLX visual (look at the difference between __GLcontextModes in glcore.h and _GLXvisualConfigRec in glxint.h), the existing inteface cannot be used[2][3].
There are a couple other issues. The current interface is not used. Not even the gamma driver does any useful work in its createContext handler (see glint_dri.c, line 825). The same goes for the destroyContext routines. By reading the documentation and comments in the code, I believe that these interfaces were created when DRI was in its infancy for drivers that might do context specific work (i.e., a per-context SAREA, etc.). Here we are 4 years later and not a single driver uses those interfaces. We can ask around, but I doubt that any of the closed-source drivers make any more use of these interfaces than the open-source drivers.
My vote is that the *protocol* for XF86DRICreateContext, XF86DRIDestroyContext, XF86DRIOpenFullScreen[4], and XF86DRICloseFullScreen be removed. That is, the client-side routines should be no-ops (to maintain backwards compatability) and the server-side routines should just return success (again, to maintain backwards compatability). The the best of my knowledge, no driver has ever used the FullScreen functionality. If a driver needs shared, per-context state, it should use its DRM.
The drawable related protocol cannot and should not be removed. However, I believe that libGL should export these interfaces to the client-side driver via glXGetProcAddress. This would allow the libGL for DirectFB, for example, to do something different.
It *may* be possible to have libGL make the XF86DRICreateDrawable call and pass the hHWDrawable into the drivers createNewDrawable routine. If createNewDrawable returns failure, libGL would call XF86DRIDestroyDrawable. The destroyDrawable would be changed (a new interface called destroyNewDrawable, perhaps?) to return the hHWDrawable value. libGL would then call XF86DRIDestroyDrawable after returning from the driver's destroyNewDrawable function. I'm not sure this would be worth the effort. Perhaps someone interested in supporting DRI outside of XFree86 can comment?
If all of the above changes and the other interface changes proposed in [1] were made, the only XFree86-specific call made from within the driver would be XF86DRIGetDrawableInfo. That function really does have to stay. :) However, like I said before, it should be accessed via glXGetProcAddress.
To maintain backwards compatability, we would need functions in dri_util.c to adapt the old interfaces to the new. In all the cases that I have seen, this would be trivial. We would want to wrap all of these functions with something like "#ifndef DRI_NEW_API_ONLY". That would allow drivers to be built that would work with or without XFree86 or drivers that would work only with XFree86.
I can generate a fairly rough patch this weekend for dri_util.c, the code in programs/Xserver/GL/, and the code in lib/GL/glx, but supporting all the drivers will take more work. I think that if we pursue this, it should be done in a branch.
If we can get some agreement on how to handle this in dri-devel, I will take the issue to [EMAIL PROTECTED] Perhaps this can make for some lively discussion at next Monday's #dri-devel meeting? :)
[1] http://marc.theaimsgroup.com/?l=dri-devel&m=106210013822486&w=2 [2] http://marc.theaimsgroup.com/?l=dri-devel&m=104862475709280&w=2 [3] http://sourceforge.net/mailarchive/message.php?msg_id=5341553 [4] http://marc.theaimsgroup.com/?l=dri-devel&m=105486181204323&w=2
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
