[PATCH xserver] present: cap the version returned to the client

[Adam Jackson]

On Wed, 2018-03-21 at 09:02 -0600, Keith Packard wrote:
> Julien Cristau <jcristau at debian.org> writes:
> 
> > Doesn't this break when e.g. client supports 2.2 and server supports
> > 1.4, where we'll return 2.2 instead of 1.4?  i.e. it seems to me this
> > should be
> > 
> > if (rep.majorVersion > stuff->majorVersion ||
> >     (rep.majorVersion == stuff->majorVersion &&
> >      rep.minorVersion > stuff->minorVersion)) {
> >      ...
> > }
> 
> Yeah, probably. Of course, we will "never" have a major version change
> as that would indicate an incompatible change in the protocol.

AFAICT most extensions that have both major and minor numbers could not
reasonably support multiple major numbers within a single server. At
best we save the version number the client sent in QueryVersion as per-
client state, but multiple unrelated parts of the client app could want
to speak different versions of the protocol (XInput went through this
IIRC). The client does not encode which version it thinks it is
speaking at any one moment; it is difficult for it to do so without
threading a context all the way through the client API. QueryVersion
could certainly just go ahead and create a context, if the client side
knew to do that.

Fixes only has a major number, which has the consequence that you're
technically never allowed to drop features, and that if version 5 is
distasteful or unimplementable in some environment version 6+ can never
be either. Also not great, but also an argument against fixes as a
junk-drawer extension.

- ajax