[Xcb] xinput.xml review, how to post many resulting changes?
Christian Linhart
chris at DemoRecorder.com
Tue Aug 12 04:37:59 PDT 2014
Hi,
I have reviewed the xinput.xml protocol definition file
by comparing it with the spec at
http://cgit.freedesktop.org/xorg/proto/inputproto/tree/specs/XI2proto.txt
http://cgit.freedesktop.org/xorg/proto/inputproto/tree/specs/XIproto.txt
For xinput-version < 1.5 I have used the spec contained in libXi-1.7.4 because that
contains a lowlevel protocol spec.
When I was in doubt about the lowlevel meaning of the spec XIproto.txt and XI2proto.txt,
I have looked at the headers XI.h, XIproto.h, XI2proto.h, XI2.h,
and sometimes also in the code of libXi-1.7.4
or the current git-master version of xorg/xserver.
Of the differences which I have found,
I have fixed those which can be fixed with the
current featureset of the xml and the generator.
For the other issues, I have written a TODO-list for the differences
which require changes in the xml-format and/or the generator
(and included the TODO-list in xinput.xml as a comment,
which one of my proposed changes).
All of this has resulted in a long list of changes.
A list of short descriptions for each change is in the P.P.S.
of this mail.
Since this quite a large number of changes,
how do you recommend I should post the changes here?
I guess I should post each change in a seperate email,
so that it can be discussed, accepted or rejected seperately.
But maybe I shouldn't post all changes at once,
because that may be overwhelming and therefore too much
for discussing and handling them properly.
So I can, for example, post them in batches of 8, or batches by category.
Once the discussion is finished and the changes are either accepted, revised or rejected,
I will post the next batch of changes.
And so on.
What do you think?
Chris
P.S.: I have done the same with xkb.xml, but some of the changes
are not yet organized in individual changes.
But I'll do that later and post these changes, too.
P.P.S.: Here's the list of descriptions of the changes, grouped by category:
*** Padding errors in the middle of requests ( these are rather critical errors ): ***
* ChangeFeedbackControl: add missing pad after field "feedback_id"
* SetDeviceModifierMapping: fix length of pad after field keycodes_per_modifier from 1 to 2
*** Clean up: ***
* struct XIDeviceInfo: field "name": replace manual padding with align-pad
*** Things that are needed but cannot be supported with the current featureset
of the xcb-xml and the generator: ***
* add TODO list of things which cannot be done yet with the current feature-set of xml and the generator
* GetDeviceMotionEvents: add commented-out proposal for unsupported stuff
*** Missing align-pads at the end of requests and replies:
( These are not as critical as padding errors in the middle of requests and replies
but can become necessary when we use assertions to compare request/reply-length
with interpretation of the data using xcb-protocol defs ) ***
* add align-pad at the end of OpenDevice-reply
* UngrabDevice: add missing pad at the end of the request
* UngrabDeviceButton: add missing pad at the end of the request
* AllowDeviceEvents: add missing pad at the end of the request
* SetDeviceFocus: add missing pad at the end of the request
* GetDeviceKeyMapping: add missing pad at the end of the request
* GetDeviceButtonMapping: add missing align-pad at the end of the reply
* ChangeDeviceProperty: add missing align-pad at the end of the request
* GetDeviceProperty: add missing align-pad at the end of the reply
* struct AddMaster: add missing align-pad at the end
* XIGetProperty: add missing align-pad at the end of the reply
* GetDeviceMotionEvents: add missing pad at end of request
*** Type errors: ***
* GetDeviceMotionEvents: replace CARD32 by INT32 in comments for list valuators/axisvalues
* XIQueryPointer: fix type of reply-field "same_screen" from CARD8 to BOOL
* struct AddMaster : fix type of fields "send_core" and "enable" to BOOL
* GrabDeviceButton: change type of owner_events from CARD8 to BOOL according to spec
* event Enter: change type of fields "same_screen" and "focus" from CARD8 to BOOL according to spec
*** Enum/mask: ***
* add missing value Attach=7 to enum InputClass
* ChangeKeyboardDevice: replace GrabStatus by new enum ChangeDeviceStatus because DeviceFrozen has a different value
* ChangePointerDevice: replace GrabStatus by new enum ChangeDeviceStatus because DeviceFrozen has a different value
* GrabDeviceKey: add new altenum ModifierDevice to field modifier_device for UseXKeyboard
* UngrabDeviceKey: add new altenum ModifierDevice to field modifier_device for UseXKeyboard
* GrabDeviceButton: add new altenum ModifierDevice to field modifier_device for UseXKeyboard
* UngrabDeviceButton: add new altenum ModifierDevice to field modifier_device for UseXKeyboard
* struct ValuatorState: add new enum ValuatorStateModeMask as mask to field "mode"
* request ChangeFeedbackControl: add new enum ChangeFeedbackControlMask to field "mask" as mask
* struct ScrollClass: field "flags": ScrollFlags is used as a mask
* struct XIDeviceInfo: field "type": replace altenum by enum because only the values of DeviceType are permitted
* event DeviceKeyPress: add mask KeyButMask to field "state"
* event DeviceMappingNotify: add enum "Mapping" for field "request"
* event ChangeDeviceNotify: add new enum "ChangeDevice" for field "request"
* event DeviceKeyPress (and derived ones): add new mask "MoreEventsMask" to field "device_id"
* event DeviceStateNotify: add mask "MoreEventsMask" to field "device_id"
* event DeviceKeyStateNotify: add mask "MoreEventsMask" to field "device_id"
* event DeviceButtonStateNotify: add mask "MoreEventsMask" to field "device_id"
* event BarrierHit: add new enum BarrierFlags to field "flags"
*** Misc: ***
* replace initial pad=1 of all Xinput-1.x replies with CARD8-field xi_reply_type, according to XIproto.h
* add comment about field "status" of SetDeviceMode-reply
* XIPassiveGrabDevice: request-field "time": Add comment that this field is missing in the spec.
More information about the Xcb
mailing list