Bug 6786 - xorg fixes module should not return BadRequest on higher fixes client versions
Summary: xorg fixes module should not return BadRequest on higher fixes client versions
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: highest critical
Assignee: Xorg Project Team
QA Contact:
Depends on:
Blocks: xorg-7.2
  Show dependency treegraph
Reported: 2006-04-30 03:58 UTC by Jan de Groot
Modified: 2006-11-08 09:04 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Jan de Groot 2006-04-30 03:58:15 UTC
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.
Comment 1 Keith Packard 2006-05-01 11:59:09 UTC
This doesn't make sense to me; the QueryVersion code carefully bounds the
negotiated extension version to those supported by both client and server.
Comment 2 Jan de Groot 2006-05-01 18:50:35 UTC
The reference to our bugtracker:

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)
    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.
Comment 3 Egbert Eich 2006-05-04 00:37:29 UTC
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,
Comment 4 Adam Jackson 2006-11-08 09:04:47 UTC
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.