Changing pixelformat on the fly

[James Weatherall]

> > You wrote:
> > 
> > In sprite.c, we have:
> > 
> > pPriv->DisplayCursor = pScreen->DisplayCursor;
> > ...
> > pScreen->DisplayCursor = rfbDisplayCursor;
> > 
> > Which is the line that sends a framebuffer update?
> 
> It's in the rfbDisplayCursor function. 

There is no call to that function in the above two lines of code, though!

> > That code appears to be missing the test for the client's 
> request region not
> > being empty.  The correct test can be copied from the 
> cursor position
> > updating code.  
> 
> Ok. I must admit that I don't understand this piece of code.

Just copy the test that wraps the rfbSendFramebufferUpdate call that is made
when the cursor moves, and put it around the call to
rfbSendFramebufferUpdate that is made when the cursor shape changes.  That
will fix the bug.

> Yes, a fix would be nice, but as I said, we'll need to deal 
> with "buggy" 
> 1.2.9 servers anyway. So, my plan is to disable pixel formats 
> change on 
> the fly, if the RFB version is <= 3.7.

Since the bug is only in TightVNC, and since TightVNC has its own
pseudo-SecurityType for the purposes of enabling the TightVNC protocol
messages, you should probably use that in conjunction with the protocol
number to determine whether to disable on-the-fly pixel format changes.  If
you report the problem to the TightVNC developers then I'm sure they will be
able to put in a simple test of this sort.

> The bandwidth can change dynamically during a session. Also, 
> the current
> TightVNC vncviewer4 starts off in fullcolor mode, unlike the 
> RealVNC 4.0
> version.

That's another bug you probably want to report to the TightVNC team!
Although, are you sure that you haven't simply overriden the FullColour
option to be true in the viewer, causing it to start in full colour mode?

Cheers,

Wez @ RealVNC Ltd.