From: Ian R. <id...@us...> - 2003-05-08 18:50:46
|
Leif Delgass wrote: > I noticed a compiler warning in the new glx code that is coming from a > prototype mismatch between the createContext() callback prototype in > glxclient.h and the declaration of driCreateContext() in dri_util.c. The > prototype in glxclient.h has added a parameter: __GLXFBConfig * fbconfig, > which is not present in the driCreateContext() declaration. In > glXCreateContext, NULL is passed for this parameter, but it is (or it will > be) needed for glXCreateNewContext and glXCreateContextWithConfigSGIX. Correct. > My question is, how should this be fixed? I'm not sure what the > requirements are here for binary compatibility. Should the fbconfig > parameter be added to the driCreateContext() declaration, or is a separate > entry point required? Also, will the DriverAPI CreateContext() callback > need this parameter as well? It should be fixed by fully implementing SGIX_fbconfig. :) As long as a driver does not export GLX_SGIX_fbconfig, the fbconfig parameter will never be non-NULL. If GLX_SGIX_fbconfig is exported, exactly one of vis and fbconfig will be non-NULL depending on whether glXCreateNewContext or glXCreateContext is called. I was going to start working on this, but I came across a whole heap of issues that greatly complicated things. I don't really understand what the various XF86DRI* calls are all about. There's also the issue of the DDX driver communicating the list of fbconfigs to the GLX extension. Even worse, we have to make sure that the DDX driver and the 3D driver agree on the list of fbconfigs. When I got to this point, I basically stopped working on it. My personal opinion is that the fbconfig information should only live in the 3D driver. libGL could directly query the 3D driver for the list of supported fbconfigs, or the GLX extension should load the 3D and call into it to get the list of available fbconfigs. I strongly feel that putting that information in both places will only lead to developer suffering. Of course, that still only solves part of the problem. How do we determine the set of fbconfigs to export when we fallback to software based indirect rendering? I think this is a problem that will be very hard to solve without either breaking backwards compatability or providing a non-full featured implementation. |