[PATCH videoproto] Xvproto: fix xvEncodingInfo to match actual wire protocol
Julien Cristau
jcristau at debian.org
Mon Jun 10 02:55:40 PDT 2013
On Mon, Jun 10, 2013 at 11:41:00 +0200, Daniel Martin wrote:
> On 9 June 2013 19:00, Julien Cristau <jcristau at 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.
>
No. As said in the commit message, the server never sent the extraneous
pad bytes, so this patch doesn't change either the server or libXv
behaviour. Both it and libXv use sz_xvEncodingInfo, which is ok.
> 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.
>
Looks like padl3 should really be CARD16...
Cheers,
Julien
More information about the xorg-devel
mailing list