[Xcb] xinput.xml review, how to post many resulting changes?

[Christian Linhart]

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.