[PATCH 3/4] Generate swrast GLX extension list, rather than using a fixed list

[Jon TURNEY]

On 24/07/2012 19:11, Jeremy Huddleston Sequoia wrote:
> I don't really like having redundant data. Is there really a need for us
> to store glx_enable_bits in the DRI screen record? It seems like we could
> just keep that local to __glXDRIscreenProbe.

It's just written that way to make it the same as glxdri.c and glxdri2.c
(There's probably some refactoring of duplicate code which could take place, also)

> On Jul 20, 2012, at 05:54, Jon TURNEY wrote:
>> Ensure this kind of bug doesn't occur in future, by generating the GLX extension
>> list for swrast, in the same way as dri and dri2 do, rather than using a fixed
>> list of GLX extensions for swrast.
>>
>> We explicity select the extensions reported by swrast rather than using
>> __glXInitExtensionEnableBits(), to maintain the historical behaviour, which is
>> slightly different:
>>
>> - GLX_SGIS_multisample is not reported on APPLE
>> - GLX_SGIX_visual_select_group isn't reported
>>
>> (How swrast handles GLX_MESA_copy_sub_buffer still looks a bit wonky: We always
>> enable it, but then subsequently also check if the loaded driver supports it,
>> and if it doesn't all glxCopySubBufferMESA() calls are just going to fail
>> GLXBadDrawable as the copySubBuffer function pointer is NULL.  This probably
>> isn't a practical concern.)
>>
>> Signed-off-by: Jon TURNEY <jon.turney at dronecode.org.uk>
>> ---
>> glx/glxdriswrast.c |   36 ++++++++++++++++++++++++++++++++++++
>> glx/glxscreens.c   |   14 +-------------
>> 2 files changed, 37 insertions(+), 13 deletions(-)
[...]
>> +#ifndef __APPLE__
>> +    __glXEnableExtension(screen->glx_enable_bits, "GLX_SGIS_multisample");
>> +#endif

As far as I can tell, this conditional is entirely pointless (now, I'm
guessing that there is some historical reason for it), as this GL provider is
never used by Xquartz.  Perhaps you can confirm that?