VNC client expectations

[Dave Hudson]

Hi James,

James ''Wez'' Weatherall wrote:
> 
> 	The rule when writing VNC clients is that they should not perform pixel
> translation internally unless they have good reason to do so, such as
> having pixel translation hardware.  All servers must therefore support
> as many pixel formats as they can.  The most obvious to support are 32,
> 16 and 8 bit truecolour formats.  The current Windows VNC viewer
> violates this rule and tends to just ask the server for whatever pixel
> format is offered.

I had inferred this from the current spec - when I saw that VNCViewer 
didn't do this I was a little surprised (much like that it accepted a 
big-endian format for pixel data where my Linux viewer will only work 
with little-endian pixel data).

Has pseudo-colour (palette based) really had much use?  I'm wondering 
because if it's frequently available then this might be a nice way to 
handle embedded VNC servers (I'm writing just such an implementation for 
the Ubicom IP2022 right now).  If not then I guess 8 bpp true-colour 
will suffice when effectively providing a remote 1 bpp viewer - sadly it 
doesn't work so well for a 2 bpp or 4 bpp mono display and I guess a 16 
bpp true-colour display would be required to just get greyscales (this 
is just a little bandwidth hungry).

> 	Protocol version 3.5 was never officially released and something better
> is in the pipeline anyway, so just ignore that.  In any case, the server
> is entirely at liberty to implement a lower protocol version than the
> client - the client should not use 3.5-specific features with a 3.3
> server.  Equally, a 3.5 server should not use 3.5-specific features with
> a 3.3. viewer.

Are there any hints anywhere as to how things will be evolving?


Thanks,
Dave