[RFC PATCH inputproto] Add XIGetSupportedVersion request
Jasper St. Pierre
jstpierre at mecheye.net
Wed Jan 23 21:27:58 PST 2013
For more details, since our use case right now doesn't actually care about
the client's requested version, omitting the version the client requested
is fine for me. If it's needed in the future, we can look at the use case
then to see if it needs the XI_QueryVersionCalled event.
On Wed, Jan 23, 2013 at 10:22 PM, Jasper St. Pierre
<jstpierre at mecheye.net>wrote:
> This sounds like a good idea to me.
>
>
> On Wed, Jan 23, 2013 at 8:38 PM, Peter Hutterer <peter.hutterer at who-t.net>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.
>>
>> XI2proto.h | 30 +++++++++++++++++++++++++++++-
>> specs/XI2proto.txt | 34 ++++++++++++++++++++++++++++++++++
>> 2 files changed, 63 insertions(+), 1 deletion(-)
>>
>> diff --git a/XI2proto.h b/XI2proto.h
>> index 4cdaa0d..e99c9d6 100644
>> --- a/XI2proto.h
>> +++ b/XI2proto.h
>> @@ -94,9 +94,10 @@
>> #define X_XIGetProperty 59
>> #define X_XIGetSelectedEvents 60
>> #define X_XIBarrierReleasePointer 61
>> +#define X_XIGetSupportedVersion 62
>>
>> /** Number of XI requests */
>> -#define XI2REQUESTS (X_XIBarrierReleasePointer - X_XIQueryPointer + 1)
>> +#define XI2REQUESTS (X_XIGetSupportedVersion - X_XIQueryPointer + 1)
>> /** Number of XI2 events */
>> #define XI2EVENTS (XI_LASTEVENT + 1)
>>
>> @@ -833,6 +834,33 @@ typedef struct {
>> } xXIBarrierReleasePointerReq;
>> #define sz_xXIBarrierReleasePointerReq 8
>>
>> +/**
>> + * Retrieve the server-supported X Input extension version.
>> + */
>> +
>> +typedef struct {
>> + uint8_t reqType; /**< Input extension major code
>> */
>> + uint8_t ReqType; /**< Always
>> ::X_XIGetSupportedVersion */
>> + uint16_t length; /**< Length in 4 byte units */
>> +} xXIGetSupportedVersionReq;
>> +#define sz_xXIGetSupportedVersionReq 4
>> +
>> +typedef struct {
>> + uint8_t repType; /**< ::X_Reply */
>> + uint8_t RepType; /**< Always
>> ::X_XIGetSupportedVersion */
>> + uint16_t sequenceNumber;
>> + uint32_t length;
>> + uint16_t server_major_version;
>> + uint16_t server_minor_version;
>> + uint16_t client_major_version;
>> + uint16_t client_minor_version;
>> + uint32_t pad1
>> + uint32_t pad3;
>> + uint32_t pad4;
>> + uint32_t pad5;
>> +} xXIGetSupportedVersionReply;
>> +#define sz_xXIGetSupportedVersionReply 32
>> +
>>
>> /*************************************************************************************
>> *
>> *
>> * EVENTS
>> *
>> diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
>> index d30fcca..b5d9afd 100644
>> --- a/specs/XI2proto.txt
>> +++ b/specs/XI2proto.txt
>> @@ -62,6 +62,7 @@ Changes in version 2.3
>> ----------------------
>>
>> - Pointer barrier events added
>> +- XIGetSupportedVersion request added
>>
>> // ❧❧❧❧❧❧❧❧❧❧❧
>>
>> @@ -2035,6 +2036,39 @@ assigned and the client must re-issue the
>> XIBarrierReleasePointer request.
>> If the device is not a master pointer device, a BadDevice error results.
>> If the barrier does not name a valid barrier, a BadValue error results.
>>
>> +XIGetSupportedVersion
>> +^^^^^^^^^^^^^^
>> + ┌───
>> + XIGetSupportedVersion
>> + ▶
>> + server_major_version: CARD16
>> + server_minor_version: CARD16
>> + client_major_version: CARD16
>> + client_minor_version: CARD16
>> + └───
>> +
>> +This request queries the server for its supported XI2 version, and the
>> +version this client has already registered for. It is side-effect free.
>> +
>> + server_major_version
>> + Major XI2 version supported by the server.
>> + server_minor_version
>> + Minor XI2 version supported by the server.
>> + client_major_version
>> + Major XI2 version this client has registered for.
>> + client_minor_version
>> + Minor XI2 version this client has registered for.
>> +
>> +XIGetSupportedVersion returns the current supported server major/minor
>> +version. It does not register this client for XI2 support and clients
>> must
>> +call XIQueryVersion with the version they support before issuing other
>> XI2
>> +requests.
>> +
>> +XIGetSupportedVersion returns the major/minor version requested by this
>> +client in a previous XIQueryVersion request. If the client has not
>> +previously called XIQueryVersion, client_major_version and
>> +client_minor_version is 0.
>> +
>>
>> [[events]]
>> Events
>> --
>> 1.8.1
>>
>>
>
>
> --
> Jasper
>
--
Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130124/c0a39d1a/attachment.html>
More information about the xorg-devel
mailing list