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 <[email protected]> > >> > >> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
