[RFC PATCH inputproto] Add XIGetSupportedVersion request

[Peter Hutterer]

On Thu, Jan 24, 2013 at 08:16:26AM +0100, Daniel Martin wrote:
> On Thu, Jan 24, 2013 at 11:38:55AM +1000, Peter Hutterer wrote:
> > XIQueryVersion sends the client-supported version to the server. The server
> > then uses that version to adjust the behaviour of XI2 for this client.
> > Current examples include:
> > * XIQueryPointer will not set the button mask for touch events if the client
> >   is XI 2.2-aware
> > * RawEvents are sent to XI 2.1 clients if a grab is active
> > * XIAllowEvents will accept different values from XI 2.2 clients
> > 
> > This behaviour is an issue for libraries supporting XI2. A library that
> > calls XIQueryVersion before the client will lock in behaviour that the
> > client may not request. A library that calls XIQueryVersion after the client
> > may trigger BadValue errors if the libraries requested version differs from
> > the client's requested version.
> > 
> > This request adds a side-effect free version of XIQueryVersion. It returns
> > the server version and the already-requested client version (if any). A
> > library may use this request to query the server for the XI2 version
> > withouth locking in any behaviour for the client.
> > 
> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > ---
> > I was tempted to call this XIQueryServerVersion but IMO that is too close to
> > XIQueryVersion.
> > 
> > Returning the client version is to determine what the client actually
> > expects in behavior. Not 100% sure if needed, but if it is needed this opens
> > another question: do we need a XIQueryVersionCalled event? If the library
> > calls XIGetSupportedVersion before the client calls XIQueryVersion, it
> > won't have the information. Unless it keeps calling it until it gets a
> > number back, which doesn't seem useful either.
> 
> Do we really need an additional request? Can't we reuse XIQueryVersion
> for this?
> - XIQueryVersion has enough padding at the end for additional fields
>   (i.e. supported_server_{major,minor}_version)
> - and/or XIQueryVersion could just return the supported server version,
>   when called with client_major = client_minor = 0.

good point.  I thought about this (and implemented it initially, it's a 5
line patch) but the thing I don't like too much is that we're changing
behaviour.  Currently the server returns BadValue for 0.0, we'd be changing
that behaviour. Not that I expect a lot of clients to care about that. The
extra request is little more code, most of it is just boilerplate.

fwiw, the first option alone doesn't work, because while you can tell when
to read the extra fields, you'd still be locking in whatever the version is
you sent. So a 0.0 request is definitely needed (thought about
SHORT_MAX.SHORT_MAX too, but that's actually a valid one in the current
server, we can't use anything > 2.0)


> The proposed XIQueryVersionCalled event might be more important. But,
> how long should the library wait for it, i.e. what if:
> - the client never calls XIQueryVersion, cause it doesn't use XI on its
>   own or
> - the client postpones XIQueryVersion until it opens a sub-window
>   (Hopefully, every client initializes it at program start - but, in
>   theory it's possible.)

The event is not something the library could wait for. It's informative
only, much like the proposed client_version fields. The library may chose to
ignore it (which Jasper said he's likely to do anyway).

The event doesn't really change much for the library, it just reduces the
need to ask for the client version repeatedly to dealing with the event
if/when it comes in.

Cheers,
   Peter