[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