[Xcb] Alignment problems in XKB GetGeometry

Daniel Martin consume.noise at gmail.com
Sun Aug 4 16:21:10 PDT 2013


On Sun, Aug 04, 2013 at 11:57:10PM +0300, Ran Benita wrote:
> I've been wanting to test XKB's GetGeometry request. However I've hit an
> impasse before I got to the interesting parts (some test code attached).
> 
> First there a difference between the XKB spec and Xlib / X server. The
> spec says:
> http://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#appD::Requests
> 
> 1     CARD8          opcode
> 1     19          xkb-opcode
> [...]
> 2     p          nProperties
> [...]
> f     KB_COUNTED_STRING16          labelFont
> 8p     LISTofKB_PROPERTY          properties
> [...]
> 
> KB_PROPERTY     4+n+v
> 2     n          nameLength
> n     STRING8          name
> 2     v          valueLength
> v     STRING8          value
> 
> Which implies (AFAIK) that there is no padding. This is what xkb.xml
> has.
> However the X server has:
> http://cgit.freedesktop.org/xorg/xserver/tree/xkb/xkb.c?id=b6e5c4669e0db391966deb397e8c975ec7f0124d#n4406
> 
> XkbWriteGeomProperties(char *wire, XkbGeometryPtr geom, Bool swap)
> [...]
>         wire = XkbWriteCountedString(wire, prop->name, swap);
>         wire = XkbWriteCountedString(wire, prop->value, swap);
> [...]
> 
> Which implies there *is* padding between and after name and value
> (aligning n+2 to 4 bytes). This is implemented in xkb.xml as
> CountedString16.
> 
> Now if I try to change xkb.xml to read simply:
> 
> 	<struct name="Property">
> 		<field name="name" type="CountedString16" />
> 		<field name="value" type="CountedString16" />
> 	</struct>
> 
> Then struct xcb_xkb_property_t is empty, which is undefined behavior
> (AFAIK) and doesn't work anyway (the padding calculations becomes
> confused). If I try to inline the CountedString16 definition into
> Property, it doesn't work either.
> 
> Are there any suggestions on how I might proceed?

The generated struct is empty, because variadic length fields will be
omitted. But, having an empty struct at the end is suboptimal. Sure.

Did you saw the new functions, that've been generated due to the change
in the struct?:
  xcb_xkb_counted_string_16_t *xcb_xkb_property_name (const xcb_xkb_property_t *R  /**< */)
and
  xcb_xkb_counted_string_16_t *xcb_xkb_property_value (const xcb_xkb_property_t *R  /**< */).


I hope that helps,
    Daniel Martin


More information about the Xcb mailing list