[Xcb] xlib on xcb.

[Jamey Sharp]

On Sun, Mar 06, 2005 at 03:47:58PM -0500, Jeremy Kolb wrote:
> Can anyone fill me in on how xlib uses xcb?  I looked through some of 
> the code and it looks like the proto functions use xcb?  So am I correct 
> in assuming that while some things use xcb for internal funness all the 
> extensions etc. still use xlib's transport stuff?

I was going to point you at my last paper, "How Xlib is Implemented",
but while looking in it for the answer to your question, I discovered
that I didn't really answer your question there. Seems like it would
have been natural to go into a little more detail on that subject in the
paper...

I still recommend reading that paper for background, but here's your
answer. The minimal changes to Xlib required to port it to XCB are
these:

Modify XOpenDisplay to delegate most of the work to XCBConnect, then
copy values from the connection setup data to the Display object, as
well as stashing the XCBConnection itself in the Display. Some auxiliary
public Xlib functions need implementation changes to support this. These
bits are in X11/src/xcl/display.c, and X11/src/OpenDis.c.

Make the Display and the XCBConnection share their output buffer and
associated state; the state consists mostly of various sequence numbers.
This is hard. It's implemented by hooking the LockDisplay and
UnlockDisplay macros so that when Xlib "locks":
  * parts of the XCBConnection are locked, and
  * the Display is updated to match the state of the XCBConnection.
On unlock, the reverse happens:
  * the XCBConnection is updated to match the state of the Display, and
  * the same parts of the XCBConnection are unlocked.
This stuff is implemented in X11/src/xcl/xcblock.c. It's how we get
binary compatibility with extensions and even the rest of Xlib's
insides.

Finally, those parts of XlibInt.c that use the file descriptor of the
server socket, or that use the event queue in the Display, need to be
re-implemented to delegate to XCB. That's in X11/src/xcl/io.c.

There are other source files touched by the above changes, but I don't
remember off-hand which ones. You can find all the differences by
searching for USE_XCB.

The proto.c bits are just there to provide (possibly) more efficient
implementations of protocol layer Xlib functions, and to provide some
evidence that Xlib and XCB calls may be mixed freely. Some of them are
startlingly difficult to get right, due particularly to the GC cache.
I've been meaning to back all of proto.c out and go back to working with
the minimal-patch version of Xlib/XCB, just in case I screwed up
somewhere in there.

Hope that helped...

--Jamey