At 2:41 PM -0700 4/13/05, Ian Romanick wrote:
Torrey Lyons wrote:
At 3:42 PM -0400 4/13/05, David Dawes wrote:

On Wed, Apr 13, 2005 at 11:52:47AM -0700, Torrey Lyons wrote:

Bugzilla #1576 and the fix committed for it is only partially right.
The patch applewmExt.h is right, but patching the imported Mesa code
in extras/Mesa/include/GL/internal/dri_interface.h is the wrong thing
to do and likely has unintended side effects on other platforms. The
correct fix is just to rename __driConfigOptions in
lib/GL/apple/dri_glx.c. Thanks for pointing out the issue.


I didn't find anything that requires the external declaration of
__driConfigOptions, which is why I applied the patch as submitted.
Perhaps something should in the BUILT_IN_DRI_DRIVER case.  There
are also likely other issues with the BUILT_IN_DRI_DRIVER case.

Yes, I don't know of a specific issue, but it seems like bad practice to change an imported header file when we don't need to. The names I came up with in apple/dri_glx.c are completely arbitrary. Now that in gcc 4.0 we can't rely on static to avoid namespace collisions, those static variables should be named something more unique. In the X.Org tree I'm going to change the name of the static variables in apple/dri_glx.c. Of course there's nothing wrong with doing both this and the submitted patch.

__driConfigOptions is supposed to be exported by the DRI driver. The idea is that a configuration utility would open libGL and use glXGetDriverConfig to get the configuration options supported by the driver. If the libGL doesn't support loading DRI drivers, as I suspect is the case with the Darwin libGL, there is no reason for glXGetDriverConfig to ever return *anything* other than NULL.

Interesting. Currently glXGetScreenDriver() returns "apple" and glXGetDriverConfig() returns an empty string, but I can see that NULL is more appropriate. The idea was to make porting application code easier by making libGL look like it can load a single "apple" driver, which might some day support some configuration options. Of course, it will probably never make sense on Mac OS X to have a real loadable driver


--Torrey
_______________________________________________
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Reply via email to