Re: [gtk-vnc-devel] PATCH: Yet more endianness fixes

[Peter Rosin <peda lysator liu se>]

Daniel P. Berrange skrev:
> The changes to gvnc.c then deal with a couple of other issues. First of
> all the RealVNC server does not follow the RFB spec for CPIXEL (or the
> RFB spec is badly written). Basically when looking to see if a CPIXEL is
> 3-bytes, we just examine the VNC pixel format depth field & compare to
> 24. This is not what RealVNC does when encoding the data. It look at each
> individual colour component to see if they all fit in the most or least
> significant 3 bytes. So I change the cpixel decoding to follow this logic.

Err, the following is pretty clear to me:

"ZRLE makes use of a new type CPIXEL (compressed pixel). This is the 
same as a PIXEL for the agreed pixel format, except where 
true-colour-flag is non-zero, bits-per-pixel is 32, depth is 24 or less 
and all of the bits making up the red, green and blue intensities fit in 
either the least significant 3 bytes or the most significant 3 bytes. In 
this case a CPIXEL is only 3 bytes long, ..."

But I do agree that the spec is a unclear about what to do if you 
request a braindead pixel format with 32 bits-per-pixel and *both* the 
least and the most significant bytes unused. Braindead, as it would of 
course be saner to request a pixel format with 16 (or 8 for the really 
braindead case) bits-per-pixel in that case.

Cheers,
Peter