Xgl page - http://www.freedesktop.org/Software/Xgl

[Ian Romanick]

Michel Dänzer wrote:
> On Thu, 2005-03-10 at 05:07 -0800, Ian Romanick wrote:
>>Michel Dänzer wrote:
>>
>>>Ah, I was wondering why it wasn't using pbuffers... I'll look into why
>>>it doesn't advertise these extensions (maybe glitz could still try to
>>>use an extension if GetProcAddress succeeds for all needed functions?),
>>>but I think there might be another problem in glitz as well: For direct
>>>rendered contexts, shouldn't it use glXGetClientString(...,
>>>GLX_EXTENSIONS) instead of glXQueryExtensionsString() (and analogously
>>>for the GLX version)?
>>
>>No!  glXGetClientString will list all the extensions that libGL *can* 
>>support.  For direct-rendering there is still handshaking between libGL 
>>and the DRI driver to determine the set of extensions to actually 
>>advertise.  Using glXGetClientString for this purpose is a mistake.  For 
>>most GLX extensions, like fbconfigs and pbuffers, the extension 
>>functionality is used *before* you have a context (direct or otherwise), 
>>so how could you even make this distinction?
> 
> So how are GLX_SGIX_fbconfig and GLX_SGIX_pbuffer supposed to be
> advertised and picked up by glitz if they're only supported on the
> client side?

If they're only supported on the client side, they're *not* supported. 
If the server can't handle a glXCreateGLXPbufferSGIX request, there's 
not much you can do.

Basically, this is why I stopped working on the new memory manager.  It 
is 100% legal (and *must* be supported) for a client to create a 
direct-rendering context and an indirect-rendering context and "share" a 
pbuffer between them (just like can be done with a window).  Until the 
same driver can be loaded on the client-side & the server-side (or there 
is no client-side driver), pbuffers are DOA.

I suspect this is also one of the *technical* reasons why Nvidia doesn't 
use DRI for their drivers.  Maybe once I get that fixed they'll change 
their minds...