[xcb] Quick and dirty XCL

[Keith Packard]

Around 4 o'clock on Sep 11, Jamey Sharp wrote:

> Hypothesis: The only reason Xlib apps fail to run on XCL/Xlib
> using the LD_PRELOAD method is because the Display structure
> doesn't have a valid output buffer pointer, _XtransConnInfo
> pointer, and last request sequence number.

It's a lot more (and less) than that.  My goal is to completely replace
Xlib on every machine with XCL+XCB.  I think this is the best way to build
a transition scheme from Xlib to XCB:

	1)	Apps use existing libX11.so
	2)	Apps use new libX11.so based on XCL+XCB
	3)	Apps relink to XCL+XCB
	4)	Parts of apps and libs migrate to XCB-specific functionality
	5)	Slowly deprecate XCL in favor of XCB

So, the first step is to build a library which can provide a libX11.so 
which completely replaces the existing libX11.so for all applications.

To replace Xlib, you must provide an ABI compatible interface for all
published Xlib APIs and datastructures, including the internal interfaces 
published for extensions and other grotty bits.

That means that XCL needs to use the existing Xlib Display structure, and 
somehow manage to make the Xlib extension interfaces work.  Otherwise, 
we'll orphan every extension not yet ported to XCB/XCL.

Once XCL has a low-level ABI interface compatible with Xlib, we can just 
take all of the existing Xlib code and just use it without any changes, 
building a monolithic Xlib that is plug compatible with the existing 
library.

My idea is to split the code into pieces so that XCL becomes a collection
of libraries which libX11.so just glues into one giant monolith.  Once we 
have a complete Xlib, we can now relink applications against the pieces of 
XCL which they need, and leave the others to rot in piece (Xcms anyone?).

Apps linked against XCL can start using XCB interfaces instead of XCL 
interfaces, eventually the last XCL dependencies will be gone and the apps 
can get rid of that library as well for a complete XCB-based application.

I see the alternative as a constant game of dual development; as long as 
Xlib remains the predominant development target, new features will be 
first implemented there and then ported to XCL/XCB at some later date; 
that leaves XCL/XCB as second class libraries, which will make application 
developers very reluctant to depend on them.

Keith Packard        XFree86 Core Team        HP Cambridge Research Lab