When using the latest Xfixes 4.0 extension together with Xorg 7.0, not a single GTK program will start. This is very bad when it comes to backwards compatibility. The problem here is in xorg/xserver/xfixes/xfixes.c on line 143 a check is made for the xfixes client version. Now the most simple reaction would be: "Xfixes 4.0 belongs to xorg 7.1, so you should use it with that", but think about the situation where you're running terminal clients with Xorg 7.0 and you don't want to upgrade them, while the terminal server runs Xorg 7.1 on a local display with up to date libxfixes and fixesproto... The new xfixes extensions in libxfixes check for the version in the server anyways and return before actually doing anything, so removing the check shouldn't be a big problem. This check has been added somewhere in Xorg 6.9/7.0, as my diskless terminals don't suffer from this problem, they're running 6.8.2.
This doesn't make sense to me; the QueryVersion code carefully bounds the negotiated extension version to those supported by both client and server.
The reference to our bugtracker: http://bugs.archlinux.org/task/4535 I run Xorg 7.1RC on my test system, so the update to fixesproto and libxfixes looked good, but it wasn't when used with 7.0. The offended code is this piece: static int ProcXFixesDispatch (ClientPtr client) { REQUEST(xXFixesReq); XFixesClientPtr pXFixesClient = GetXFixesClient (client); if (pXFixesClient->major_version >= NUM_VERSION_REQUESTS) return BadRequest; if (stuff->xfixesReqType > version_requests[pXFixesClient->major_version]) return BadRequest; return (*ProcXFixesVector[stuff->xfixesReqType]) (client); } When a client with libxfixes 4.0 connects to a server which supports the XFIXES 3.x extension, it gets a BadRequest error all the time, no matter what function gets called. The libxfixes library contains code to check if the server supports a specific version of the extension, which looks right to me. When a program uses libxfixes correctly, a libxfixes 4.0 client should be able to work with a 3.0 server without problems. This piece of code in the server however throws a BadRequest to the client, no matter what call it does.
Jan is sitting next to me here on LinuxTag and it looks like we got it figured out: The commit time of the Porto version was ealier than the one of the server. He happened to pick the proto and the server code right in between. The older server code of course builds well with the newer proto code. The problem is in the server however the server code does: if (stuff->majorVersion < XFIXES_MAJOR) { rep.majorVersion = stuff->majorVersion; rep.minorVersion = stuff->minorVersion; } else { rep.majorVersion = XFIXES_MAJOR; if (stuff->majorVersion == XFIXES_MAJOR && .... XFIXES_MAJOR comes from the proto. In dispatch it does: if (pXFixesClient->major_version >= NUM_VERSION_REQUESTS) return BadRequest; which will fail of course. It sould be permissible to build a server with a newer version of the proto headers (as long as existing calls have not been changed). However the server should use it's own notion of the version - not one that it picks from the proto headers. Furthermore a pkgconfig test should check if the proto headers are older than the server version. This is a glitch that is introduced with modularization,
Fixed in master and 1.2 branch, thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.