[Xcb] [PATCH proto 2/2] xinput: Add XI version 1.5

[Daniel Martin]

On Fri, Jan 04, 2013 at 04:03:10PM +1000, Peter Hutterer wrote:
> On Thu, Jan 03, 2013 at 08:49:29PM +0100, Daniel Martin wrote:
...
> > +    <!-- ListDeviceProperties -->
> > +
> > +    <request name="ListDeviceProperties" opcode="36">
> > +        <field type="CARD8"  name="device_id" />
> > +        <pad bytes="3" />
> > +        <reply>
> > +            <pad bytes="1" />
> > +            <field type="CARD16" name="num_properties" />
> 
> this doesn't seem right, it would misalign the num_properties field. looking
> at the struct there is no pad before nAtoms.

At that point the pad is correct, as the first field results in being
between response_type and sequence in the reply. That's for replies
using this byte for informations.

> plus, the spec and the C headers use nAtoms and Atoms, maybe use the same
> naming scheme here.

I'll change that.

> > +    <!-- ChangeDeviceProperty -->
> > +
> > +    <enum name="PropertyFormat">
> > +        <item name="data8">  <value>8</value> </item>
> > +        <item name="data16"> <value>16</value> </item>
> > +        <item name="data32"> <value>32</value> </item>
> > +    </enum>
> > +
> > +    <enum name="PropertyMode">
> > +        <item name="Replace" />
> > +        <item name="Prepand" />
> 
> typo: prepend

.o0( Daniel, stop typing, use copy'n'paste. )

> > +    <event name="DevicePropertyNotify" number="16">
> > +        <!-- XXX: pad0 (byte between response_type and sequence)
> > +                  is used for the state (NewValue or Delete) -->
> > +        <pad bytes="1" />
> 
> this is odd, can't you access this byte? DeviceMappingNotify and
> ChangeDeviceNotify have the deviceid here and their xml seems
> to access it?

And at that point the pad is wrong. You're right. The field "state" can
be defined there for the same reason pad has to be the first field in
ListDeviceProperties.

This implicit field arrangement is confusing.

> either way, with the changes Reviewed-by: Peter Hutterer <peter.hutterer at who-t.net>

Thanks for reviewing.