[Xcb] [PATCH 5/7] Add event queue splitting
Uli Schlachter
psychon at znc.in
Thu Nov 7 00:35:00 PST 2013
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
More information about the xorg-devel
mailing list