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

[Keith Packard]

Peter Harris <pharris at opentext.com> writes:

> Dude. It's not getting NAKed, it's getting "Woah, this is out of left
> field, this is the first I've ever heard of it, can we please have a
> couple of days to think about it before we ACK it?"ed.

Yeah, I've been running this code for months now and have mentioned it
when presenting DRI3000, but didn't ever bring it directly to the XCB
list because I implemented precisely what we'd already agreed to in
principle -- the notion of a simple event filtering mechanism that split
events off into separate queues

I didn't realize until recently that I *hadn't* even sent the patches to
the list though; DRI3000 has so many modules involved. I have posted
links to the work since last January, and to my knowledge, no-one has
ever looked at any of the code in question, so XCB is at least not alone
in that regard.

In any case, I'd like to implore all of you to consider a little
deadline problem that I have today:

 * The Mesa freeze is Friday.

 * All of the DRI3/Present code has been reviewed and is ready to be
   merged to master for that freeze.

 * However, it cannot be merged until a released version of XCB with
   these APIs is available.

 * XCB is blocking the availability of a significant improvement to
   Mesa.

If we miss that freeze, DRI3/Present and the opportunity for GL support
in XCB will languish for at least another six months. And that would be
a shame.

The key to understanding these changes is:

 1) The notion of separate event queues with event filters to driver
    events into each queue was agreed to by several XCB developers a
    long time ago.

 2) This design has the separate event queue APIs and implementation
    matching the requirements laid out informally in the historical
    discussions.

 3) Precisely how event filtering should work was never really worked
    out. I suspect the general notion would have been some complicated
    offset/mask/match algebra to allow selection based on fields within
    the event though.

 4) I constructed the simplest possible matching system which performs
    precisely the match needed for the Present extension, with the
    notion that a more complicated matching API should wait until we
    had actual requirements for that

 5) Adding new APIs to construct more complicated filters will not
    affect any public APIs offered in this patch.

 6) GLX is the last major X API which cannot be supported in XCB; this
    fixes that, so even if we end up with a dead-end API that is only
    good for this one thing, it will still be valuable enough to support
    forever (or, for at least as long as we're running X on the desktop,
    which appears to be functionally equivalent)

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20131106/128c5ee7/attachment.pgp>