[Xcb] [PATCH 5/7] Add event queue splitting

[Josh Triplett]

On Wed, Nov 06, 2013 at 09:25:40PM -0500, Peter Harris wrote:
> On 2013-11-06 19:55, Josh Triplett wrote:
> > On Wed, Nov 06, 2013 at 02:34:03PM -0500, Peter Harris wrote:
> >> On 2013-11-05 19:41, Keith Packard wrote:
> >>> This allows apps to peel off certain XGE events into separate queues
> >>> for custom handling. Designed to support the Present extension
> >>>
> >>> Signed-off-by: Keith Packard <keithp at keithp.com>
> >>
> >> Re: xcb_register_for_special_event, xcb_unregister_for_special_event,
> >> xcb_check_for_special_event, and xcb_wait_for_special_event.
> >>
> >> There was some push-back the last time something similar to this came
> >> up, on the theory that it should be in a separate library from xcb[1].
> >> That said, we may have reached the point where it's just too useful to
> >> not have in libxcb.
> >>
> >> Does this interface work for the rest of the things needed for GLX?
> > 
> > The last time that Jamey and I spoke about this, we agreed that this
> > type of mechanism would be required to make GL work, and that there's
> > really no other way to support it.  However, I'd like to see it not
> > XGE-specific, so that it could support the existing events GL needs
> > today, not just the new Present/DRI3 approach.
> > 
> > The architecture we'd discussed was effectively that it should be
> > possible to create one or more separate event queues from the primary
> > one, add filters that peel off events into those queues (which XCB will
> > automatically apply as events arrive), and then read the next event from
> > a queue.
> 
> Now that I've had a chance to look at the implementation, it implements
> precisely what you describe[1].
> 
> Adding support for another type of filter (eg. for core events) would be
> a single additional function; the API is not married to XGE-plus-eid events.
> 
> There are a couple of minor naming niggles (eg. Perhaps
> xcb_check_for_special_event should be named xcb_poll_for_special_event
> to match the naming of the rest of the XCB poll functions, or the
> already-mentioned name of the function that creates a special
> XGE-plus-eid event queue), but that's just bikeshedding.

I would indeed like to see that name change, to go along with the change
Keith mentioned of tagging the register function with "_xge" to make
room for a future non-XGE API.

> [1] With the caveat that each new / separate event queue is created with
> exactly one filter. If you want multiple event types, you create
> multiple event queues. If the GLX people are happy with this limit, I'm
> ecstatic, since it means there aren't a bunch of functions for attaching
> filters to queues and other bookkeeping.

I can't say I'm thrilled with that approach.  Not that the API needs to
look like that right now, but I don't see any obvious way to extend the
currently proposed API to support multi-event queues in the future,
either.

- Josh Triplett