[Xcb] Status of XCB-GLX?

[Josh Triplett]

On Tue, Jan 31, 2012 at 11:57:24PM -0700, 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?  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.

XCB specifically has it as a design goal to avoid magically generating
or consuming bits of X11 protocol that the user of libxcb doesn't know
about.  That works quite well for requests, replies, and errors, because
the sequencing of those makes it straightforward to figure out what
calls they correspond to.  (Thus, even if you use xcb_take_socket to
make X calls yourself, you can process your own requests, replies, and
errors.)

Events, since they can arrive asynchronously, cause more problems here:
no sensible way currently exists for multiple cooperating handlers of
X11 protocol bits to cooperate on an event stream, hence the issue of
having to specify in advance whether XCB or Xlib owns events.

A few possibilities which have come up in the past:

- Provide a "libxcb-event", which wraps the existing XCB event interface
  and provides an event queue abstraction.  libxcb-event would then own
  the event queue, and Xlib, GLX/DRI, and other event handlers could use
  it.  Basic clients could still choose to use libxcb's event handling
  directly to speak "raw" protocol as they currently do.  This seems
  like the most workable solution, though not a very satisfying one.
  Has the major disadvantage of not cooperating with existing libxcb
  users; a solution that still allows the application to just call the
  xcb_*_event functions directly seems preferable.

- Extend the socket handoff API somehow to support handling of events.
  No idea what the new API would look like, and unless one solution
  stands out as obviously *right*, it shouldn't live in libxcb.

- Modify the existing libxcb event API to expose an event queue, rather
  than the current API which very carefully avoids ever suggesting that
  XCB queues events rather than just handing them to you immediately.
  This has the very serious danger of making this part of XCB look a lot
  like Xlib, and nobody wants that.  Again, not something we want to do
  unless one solution stands out as obviously *right*.

- Fix events somehow in an X11 extension.  For instance, add a magic
  multiplexing token which determines who wants the event, and change
  callers to use it.  Seems even less likely. :)

Suggestions welcome.

- Josh Triplett