[Xcb] Status of XCB-GLX?

[Peter Harris]

On Wed, Feb 1, 2012 at 1:57 AM, Ian Romanick wrote:
> On 01/29/2012 03:12 PM, Peter Harris wrote:
>>
>> On Sun, Jan 29, 2012 at 4:48 PM, Troy Watson wrote:
>>>>
>>>> (Note that, due to some unfortunate design decisions, most OpenGL GLX
>>>> libraries are incompatible with XSetEventQueueOwner)
>>>
>>>
>>> Can you clarify this for me?
>>
>>
>> I'm not intimately familiar with the details, but basically there are
>> evil hidden events that you're not aware of that are used by the
>> direct rendering infrastructure. Xlib hides these (by sneakily passing
>> them to somebody other than the caller of XNextEvent()), XCB does not.
>> IIRC, the OpenGL libraries don't even provide a documented entry point
>> for the events, so you can't pass them by hand.
>
>
> Gosh, if we're so evil and sneaky, perhaps you can enlighten us with a way
> to do it that is transparent to applications?

Sorry. Poor choice of words on my part. I shouldn't have used "evil".
But "a way... that is transparent to applications" is one of the
definitions of "sneaky" in my dictionary. "2. marked by quiet and
caution and secrecy; taking pains to avoid being observed".

Sneaky is a virtue in libX11, so I apologize again for calling it evil.

Josh already explained the XCB philosophy better than I could, so I'll
leave it at that.

>  Requiring the application to
> magically know that it needs to process some event and send it to the GL
> library is a non-starter.  DRI is a driver implementation detail that the
> application cannot know about.

Adding one more possibility to Josh's list:

It isn't magic if it's documented. GLXCB wouldn't be the same API as
GLX. Perhaps glXCBinit() could return a list of events that should be
passed, unmodified, to glXCBhandleEvent() or similar? The enclosing
program wouldn't even have to know which extension generates such
events.

I don't think creating an entire new gl API is a better option than
any of Josh's. I merely present it for consideration.

Peter Harris