On Wed, 2018-03-21 at 09:02 -0600, Keith Packard wrote:
> Julien Cristau <jcris...@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
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
