On Wed, Nov 06, 2013 at 06:39:19PM -0800, Keith Packard wrote: > Josh Triplett <[email protected]> writes: > > > 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. > > If you have concrete requirements for additional filtering, we can > easily construct additional API in the future offering those. In > particular, figuring out how to handle the DRI2 event stream should be > straight forward. > > I would suggest that the 'xcb_register_for_special_event' API might want > a different name to make it clear that this is only one of potentially > many ways to construct an event filter. Perhaps > 'xcb_register_special_event_xge' or some such?
That sounds good. > > 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. > > That's precisely what this patch does, except that the only filter > method offered today is driven by the requirements for the Present > extension. Attempts to construct a completely general matching algebra > should wait until we have a system requiring such a mechanism. I have no interest in a general matching algebra right now; I'd prefer to see the API only matching on event numbers as it does now. - Josh Triplett _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
