On Thu, Oct 09, 2003 at 04:06:04PM -0700, Ian Romanick wrote:
> Over the past few months there has been a lot of talk about having a
> single client-side driver binary used both with and without XFree86. A
> number of stumbling blocks have been found to this. I've pointed out a
> couple times that some of these same issues also block fbconfigs and
> pbuffers. Until recently, most of my research on this problem has
> focused on the client-side. Over the last couple weeks I've done a bit
> more digging, and I've found that the rabbit hole goes much, much deeper
> than I first thought.
> 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  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.
> 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, 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
>  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
> 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 devel@.... Perhaps this can make for some lively
> discussion at next Monday's #dri-devel meeting? :)
>  http://marc.theaimsgroup.com/?l=dri-devel&m=106210013822486&w=2
>  http://marc.theaimsgroup.com/?l=dri-devel&m=104862475709280&w=2
>  http://sourceforge.net/mailarchive/message.php?msg_id=5341553
>  http://marc.theaimsgroup.com/?l=dri-devel&m=105486181204323&w=2
It would be very interesting hear Keith Whitwell and Jon Smirl about this
The part i dislike is that XF86DRIGetDrawableInfo has to stay and
backwards compatibility as this could be called DRI2 because it will have
different but cleaner and better client/server programming interfaces IMO.