Peter Harris <phar...@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.pack...@intel.com
pgpfN1hWOxrJe.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel