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?
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
