[Xquartz-dev] X Error

[Jeremy Huddleston]

>> Actually, that patch has nothing to do with libX11... that's  
>> entirely libxcb:
>>
>> http://cgit.freedesktop.org/xcb/libxcb/commit/?id=beccb0be15f5699c942a0af33307d9e4bf797e2a
>
> Does XQuartz use a libX11 built with --disable-xcb (if I recall the  
> option correctly) still?  There is a layer in libX11 that will use  
> the xcb code if possible for implementing parts of libX11.
> From what I see in an older configure the option is --with-xcb.  I'm  
> not sure if it's a default when the libxcb is available.

Yes, we explicitly use --without-xcb to build libX11 just in case.

> If I recall correctly I ran into this problem on the Mac before,  
> because recent libX11 try to use libxcb by default, and that was  
> causing an assertion to fail somewhere in libxcb with one of the GLX  
> tests, and from all appearances the code path and LockDisplay()  
> usage appeared correct in that path.

Yeah, we definitely don't use xcb.  libxcb wasn't even working with  
the launchd DISPLAY socket until 2.3.2, I believe... so we would've  
seen major breakage if it was used in libX11.

>> libxcb is still not mature enough in my opinion.  I think that it is
>> definitely getting there, but not there yet.
>
> I agree.  libxcb is also missing an extension or 2, and the API is  
> very different than Xlib/libX11.

I think most of the extensions in libxcb + xcb-util cover what most  
clients will want.  It doesn't have AppleWM for example, but I don't  
plan on rewriting quartz-wm to use xcb, so /shrug.

> It's supposed to have much better thread support, a more async API,  
> and they have used the Z formal method to prove the code correct in  
> some areas.  There was an interesting usenix paper about how the XCB  
> developers used Z.
>
> http://www.usenix.org/events/usenix02/tech/freenix/full_papers/massey/massey_html/index.html

Neato.