On 10 June 2013 11:55, Julien Cristau jcris...@debian.org wrote:
On Mon, Jun 10, 2013 at 11:41:00 +0200, Daniel Martin wrote:
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
On 06/ 9/13 10:00 AM, Julien Cristau 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
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
On Mon, Jun 10, 2013 at 11:41:00 +0200, Daniel Martin wrote:
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
Julien Cristau jcris...@debian.org writes:
Both it and libXv use sz_xvEncodingInfo, which is ok.
Am I right code is always supposed to use the sz_ constants, not
sizeof? Not that that would be an excuse to break anything.
If in doubt I suppose could put the intended pad before, but leave the
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
6 matches
Mail list logo
