On 9 June 2013 19:00, Julien Cristau <jcris...@debian.org> wrote: > The padding is *before* the rate field, so the rate is placed on a 32bit > boundary. This change adds explicit padding between height and rate, > and removes extraneous padding after the rate field, which the server > never sent and xlib never read. > > This changes sizeof(xvEncodingInfo). Hopefully that's not a big deal as > clients only see the Xlib structure XvEncodingInfo.
(Hopefully, I'm right with that): I think that's an ABI change and a bit more difficult. Think about an X server, which is compiled against a xvproto version without that change and the lib compiled against xvproto with that change. In that case the lib would start to read the encoding info, where the X server just sended those extraneous pad bytes. I just saw that the reply structure itself (xvQueryEncodingsReply) has such extraneous padding too: ... CARD32 length B32; CARD16 num_encodings B16; CARD32 padl3 B32; ... And even without this padding sz_xvQueryEncodingsReply=32 is wrong, as the fields sum up to 34 and with that padding we're at 36. Cheers, Daniel Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org