[Xcb] Re: Xserver/XCB

[John Davidorff Pell]

On 6 Dec 2005, at 07:29, Jamey Sharp wrote:
> I don't have much to add to what Bart said, though I'd like to echo  
> his
> point that we're very interested in supporting this work. (I think  
> it'd
> be a lot easier to implement xcb-server inside an existing server like
> X.org, but you can do it however you want. *grin*)

Thanks much for the encouragement from both of you. Its taken me a  
long time to reply, for I am quite busy. I've picked up with my  
project again now.

Part of the reason that I want to write a new X server is that I  
would like to avoid all leftover code. Since I am writing a rootless  
X server, a great many things from X.org can be dropped entirely. I  
plan on writing the server in such a way that it is quite dependent  
on the native graphics system, but because of that is fast and does  
not require the kludges that X.org's rootless support has required  
over the years, as inspired as they may be. My X server would act  
primarily as a translator.

Certain features of X will not make it into my server. For example, I  
do not have any intention to support subwindows. Any request that  
attempts to create a window with a parent other-than-the-root-window  
will fail with an Implementation error. Features which find use only  
in window managers will likewise be lost, since I plan on having the  
only supported "window manager" be the X server itself, by way of the  
native windowing system.


A more important reason to write a new X server is that this is a  
learning exercise. What better way to abuse my brain cells than to re- 
implement X!


> On Sat, Nov 05, 2005 at 12:13:22AM -0800, John Davidorff Pell wrote:
>> Does XCB implement events that are only ever generated server-side?
>> To do so, I would just need to write them in XML, no?
>
> Everything in the X wire protocol is described in the XML already, so
> while I'm not sure I understand the question, I think the answer is  
> that
> you shouldn't need to do that.

I guess my question was: Does XCB have C code for these events? i.e.  
could I link my server against libxcb.dylib and then call  
XCBPropertyNotify(window, atom, state, time) ?


While comparing the X protocol spec against xproto.xml, xproto.h, and  
xproto.c I have a significant question.
The protocol says:
	GetProperty
		window:		WINDOW
		property:	ATOM
		type:		ATOM or AnyPropertyType
		long-offset:	CARD32
		long-length:	CARD32
		delete:		BOOL
xproto.xml has "BOOL _delete" first. The reply has format first, but  
the spec as it second.

The on-wire-communication is obviously what I need to support, but is  
this possible building from only the X spec??

> On Sun, Nov 06, 2005 at 05:24:50PM -0800, Barton C Massey wrote:
>> I'm not sure how much of the rest of the XCB codebase will
>> be useful, though.  It depends partly on whether you're
>> going to try to build a multi-threaded server---there's
>> pieces that might be useful for that.  I think otherwise
>> there's not too much...
>
> That sounds about right.

I am definitely doing a multi-threaded X server, but not in the  
traditional sense. I plan on having a process dedicated to *each* X  
client, and each process would itself be multi-threaded. I plan on  
having a main loop thread, a communication thread, and a drawing  
thread (perhaps per window). This would allow asynchronous  
communication and minimal blocks. Only drawing calls that require a  
reply would tie up the whole server at once.

XCB's client-side connection code might be useful, only switch dial- 
out for accept-incoming.

> I've had this idea for a while, though, that there are some  
> interesting
> games you can play if xcb-server is a thin layer that dispatches into
> functions named identically to the xcb-client functions. Then (with a
> little bit of extra glue) you can link an XCB app directly into the X
> server, which I think might be useful under some limited  
> circumstances.
>
> The practical side of that is it'd be nice if you generate code that
> uses names and argument lists roughly identical to the ones XCB uses
> now. Otherwise it should probably have no effect on your work.

I've had that very same idea! Here's an example situation when it  
would be quite useful: rootless X server living under a native  
windowing system. An X app compiled to run natively, but use X for  
graphics, can now use the native windowing system through this linked- 
in X server! :-D

I do plan on including this type of functionality. I plan to  
implement if as a drop-in for the communication thread, which would  
allow the rest of the server to function without knowing or caring  
where the communication would be going. This might raise some  
interesting threading questions, but a well-behaved program shouldn't  
screw things up.

I'm even thinking of not needing any linking at all. Just have the X  
server load in the client binary and patch some symbols. (and include  
a tool to tell the X server to do just that.)

> --Jamey


Thanks,
	JP