[Xcb] problem when getting replies

[Jamey Sharp]

On Sun, Nov 12, 2006 at 09:26:38AM +0100, Vincent Torri wrote:
> I just do:
> 
>    _ecore_xcb_damage_init_cookie = 
> xcb_damage_query_version_unchecked(_ecore_xcb_conn, 1, 0);
> 
> and when I check the connection with xcb_connection_has_error, there is 
> indeed an error.
> What does it mean ? Is it possible that my X server does not support the 
> damage extension, which would be the reason ? And how can I check that ?

Ah. XCB can't issue the QueryVersion request for an extension unless the
extension is present and the QueryExtension response has already come
back. When you call this function the prefetch_extension_data that you
did earlier is automatically forced, and if that says the extension
doesn't exist then the connection is shut down.

To avoid having the connection shut down when the extension doesn't
exist, you need to call xcb_get_extension_data. (If you might send
requests bigger than 256kB, you should turn on BIG-REQUESTS early, too.)
In pseudo-code, your initialization should look like this:

// First round trip:
	for each atom:
		xcb_intern_atom
	for each extension + xcb_big_requests_id:
		xcb_prefetch_extension_data
	// insert more requests with no dependencies here
	for each atom:
		xcb_intern_atom_reply
	for each extension:
		extension = xcb_get_extension_data
// Second round trip:
		if(extension && extension->present)
			query_version
	// insert requests that needed atoms here
	xcb_get_maximum_request_length // enable BIG-REQUESTS
	for each extension:
		query_version_reply

That's two round trips, and you can't do any better in the X protocol, I
believe. (Bart and I were discussing yesterday that the TCP three-way
handshake and the connection setup request and reply are two more
round trips, so to be really pedantic you could say you need four round
trips to get going.) You probably need one more after the QueryVersion
replies come back to actually use the extensions you want, but I think
in 3 (or 5) round trips you're all set and ready to do real work.

BTW, you can check whether your server supports DAMAGE with either
xdpyinfo or xcbdpyinfo: both provide a list of supported extensions.

--Jamey

p.s. We should probably add a prefetch_maximum_request_length function
for initialization purposes. Currently xcb_get_maximum_request_length
always takes a round-trip the first time it's called. In the above code
I was careful to place it where we were about to block for round trip
latency anyway, but this ordering has potentially reduced parallelism.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20061112/b1658eb4/attachment.pgp