Proper handling of extension events/errors?

[Pierre Ossman]

I seem to have stumbled upon a rather horrible flaw in how extension
events and errors are handled in the Xorg ecosystem, and this is
breaking Xlib. :/

The wire protocol for extensions sends just two values, one base for
events and one base for errors. The number of events or errors are
_not_ sent over the wire, but is implicit information that the server
and client must share.

This means that the number of events/errors is an essential part of the
protocol definition, and must be treated with care. Unfortunately it
seems like people just update the number of events/errors as needed...

Right now we're seeing misbehaviours with TigerVNC on Ubuntu. The
reason being that Ubuntu has extended the number of Xfixes events from
3 to 2. So the server believes that events 90-91 are Xfixes, and 92-93
are RandR. But when the client gets event 92, it believes that is for
Xfixes and uses the wrong wire-to-event callback.

This does not seem to be isolated to libXfixes unfortunately. Looking
at libXrandr, I see the same thing. AddExtension() is called with a
fixed number of events, even though older RandR had just the one event.

So it seems like the extension libraries need some fixing. libX11 could
probably also check that an event/error slot is actually empty before
filling it.

And be a bit more cautious in the future when adding new events/errors,
as it easy to create incompatibilities. :)

For now I guess I'll have to add some padding to the server side
AddExtension() between each extension. Hopefully I won't run out of
ids...

Rgds
-- 
Pierre Ossman            OpenSource-based Thin Client Technology
System Developer         Telephone: +46-13-21 46 00
Cendio AB                Web: http://www.cendio.com

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20120416/a7bbbf16/attachment.pgp>