Hi, On 07.11.2013 04:09, Keith Packard wrote: > Peter Harris <[email protected]> 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.
Quite a convincing argument... :-P > 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. And this comes up on the xcb list two days before this deadline and only does so accidentally...? > * 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. Sorry, but this deadline might be a little close. If this patch does get in, I am OK with cherry-picking these patches into a branch and doing a release from that. But the general consensus with the whole XKB (and more) situation seems to be that master is not in a releasable state. > * 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. OK, I don't have a problem with this going in if it gets ACK'd by the "right people" (whoever that is exactly). Since I will be offline, someone else would then need to be convinced to do a new release based on 1.9.1 + these patches. > 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) That would be great, yeah. Uli P.S.: Subscribed to xorg-devel just so that my mails don't end up in the moderation queue... -- A normal person is just someone you don't know well enough yet. - Nettie Wiebe _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
