From: Ian R. <id...@us...> - 2003-05-09 16:49:11
|
Jos=E9 Fonseca wrote: > On Thu, May 08, 2003 at 01:56:25PM -0500, Leif Delgass wrote: >=20 >>On Thu, 8 May 2003, Jens Owen wrote: >> >> >>>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 * fbcon= fig, >>>>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. >>>> >>>>My question is, how should this be fixed? I'm not sure what the=20 >>>>requirements are here for binary compatibility. >>> >>>The main thing to worry about is the external interfaces. Since these= =20 >>>modules are statically linked to the Mesa driver, the external interfa= ce=20 >>>you need to maintain are: >>> >>> >>> 1) between the Mesa driver and X Server in the form of X11 protocol=20 >>>(DRICreateContext) >>> >>> 2) between the Mesa driver and libGL >>> >>> 3) between the Mesa driver and it's supporting kernel modules (DRM &= AGP) >>> >>>It looks like you mostly need to think about 1, but I doesn't sound li= ke=20 >>>you're changing interfaces at the DRI X extension protocol level so=20 >>>you're probably okay. >>> >>> >>>>Should the fbconfig >>>>parameter be added to the driCreateContext() declaration, or is a sep= arate=20 >>>>entry point required? >>> >>>Since the DRI module is statically linked w/ the driver at build time = I=20 >>>think you can just change it as long as you don't need to propegate th= e=20 >>>change down into the wire protocol. >> >>Actually, I think this function falls under item 2. driCreateContext()= is >>a static function in dri_util.c, which is installed as a callback in th= e >>__DRIScreenPrivateRec in __driUtilCreateScreen(). dri_util.c is compil= ed >>into the the loadable Mesa driver module. The GLX functions in libGL g= et >>the callback through the __DRIScreenPrivateRec. driCreateContext() and >>the other functions in dri_util.c make up the libGL/Mesa driver interfa= ce, >>and they wrap the DriverAPI functions which live in the device-specific >>code. >> >> >>>>Also, will the DriverAPI CreateContext() callback=20 >>>>need this parameter as well? >>> >>>Dunno. If you're getting into the Mesa/libGL interface (item 2 above)= ,=20 >>>you'll need to worry about binary compatability. >> >>As I explained above, it looks like the line of demarcation between lib= GL >>and the loadable Mesa modules is really in dri_util.c. So I think the >>callbacks in the DriverAPIRec can be changed without a problem, since t= hey >>are internal to the Mesa device driver. >=20 >=20 > That's right. But as you said above, driCreateContext falls between the > Mesa and libGL interface and can't be changed like that. So either a ne= w > entry point is added (but there's still the problem of how to tell libG= L > that the structure has more one entry point - at the lack of a better > mechanism you need to export a another symbol from the driver shared, > e.g., __driCreateScreen2) or backout that change for the time being. The 3D driver can determine if libGL can support the "new" calling=20 convention by calling driCompareGLXAPIVersion (lib/GL/dri/dri_util.c,=20 line 1210) with 20030317. If the libGL is new enough and the driver can=20 support it, it would call __glXEnableExtension( "GLX_SGIX_fbconfig",=20 GL_FALSE ) (lib/GL/glx/glxextensions.c, line 221) to enable the=20 extension. Then, and only then, would the additional parameter to=20 driCreateContext be used. At that point the driver and libGL will have=20 had a two-way handshake to agree that using the additional parameter was=20 valid. The exact same handshaking would have to be done if a new DriverAPI=20 entry point was added. Given that, I see no point in adding a new entry=20 point that will be 99% the same as the existing entry point. I guess the only remaining question is, "Where should we document that=20 this is the way it works?" |