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

[Peter Harris]

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.

Reviewed-by: Peter Harris <pharris at opentext.com>

Peter Harris

[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.
-- 
               Open Text Connectivity Solutions Group
Peter Harris                    http://connectivity.opentext.com/
Research and Development        Phone: +1 905 762 6001
pharris at opentext.com            Toll Free: 1 877 359 4866