Add some commentary about future directions needed for the GLX drawable
creation and destruction code.
Match xalloc with xfree.
I made some minor formatting improvements.
In attach() check for pDraw being NULL, and also print an ErrorF message,
because we eventually want to track down why this is occuring.
It's unclear how this occurs, but as I noted in the 1.4 branch, I believe that
the DrawablePtr/struct _Drawable -> id is the member being accessed that causes
KERN_PROTECTION_FAILURE at 0x0000000000000004
This passes my tests using: env LIBGL_ALWAYS_INDIRECT=1 ./sometest.
I fixed a warning: caused by initializing the screen->base.visuals with the
configs. It is a ** not a *. It seems that some other part of GLX will
initialize this for us.
It looks much better with the new GLX/libGL, perhaps because of the old libGL
not understanding all of the tags written. At least glxgears works with both.
glxgears is not a test for all OpenGL features, so most likely some things
are broken still. Direct rendering is known to not work, or at least being
reported as not working.
Fix some obvious errors with uninitialized new members of GLX structs.
Add a type argument for the screen's drawable creation function, and pass the type to
__glXDrawableInit().
GLX still doesn't work. There is more work needed to get it working again. This gets
it building at least, although there are some warnings in the dispatch table setup,
that seem to be caused by const differences.
I also #if 0ed a bunch of function bodies that will need to be revisited soon.
GL/capabilities.c: #if 0 (for now) any capabilities above 8 bits per channel,
because they introduce drawing problems.
GL/indirect.c: Comment out some visual setup code that shouldn't be running, and
actually seemed to cause some problems. The current visualConfigs.c code seems
to do a reasonable job of setting up visuals for XQuartz.
GL/visualConfigs.c: Make use of the proper visual .class. Eliminate depth 0.
It seems we really just want 24 for now, and 0 I think was a flaw in the original
code.
(cherry picked from commit 1e5f63f15e)
This gives us a *lot* more visuals, and they should be more accurate.
Some of the visuals may have been wrong before. This may enable more
OpenGL programs to behave correctly.
I also suspect libGL needs a little work to handle some of these correctly.
(cherry picked from commit 98a084ce9c)
