Using a CallbackListPtr to handle InitExtensions for GLX vendor libraries works
on the first server generation, but at the end of the generation, the server
will clear the callback list. On the second generation and beyond, every screen
ends up with NULL for the vendor handle assigned to it.

This patch avoids that problem by setting the callback list to point to a
static CallbackListRec. Since it's not allocated through CreateCallbackList, it
doesn't get added to the listsToDelete array.

Using a static CallbackListRec like this feels kind of hacky to me, but I
haven't come up with anything better.

The best alternative I've thought of would be to modify CreateContextList so
that it only optionally adds the list to listsToDelete, and then call that
to initialize the callback list. But, we'd need to make sure that the callback
list gets initialized before anything else has a chance to call AddExtension,
which seems likely to be error-prone.

I could also add functions to GlxServerExports to add and remove callbacks
instead of exposing a CallbackListPtr directly. I'm not sure if that would be
better or worse.

If anyone has a better idea or would otherwise prefer setting this up
differently, then let me know and I'll be happy to send out an updated patch.


This email message is for the sole use of the intended recipient(s) and may 
confidential information.  Any unauthorized review, use, disclosure or 
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
_______________________________________________ X.Org development

Reply via email to