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

[Uli Schlachter]

Hi,

On 07.11.2013 04:09, Keith Packard wrote:
> 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.

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