Changing pixelformat on the fly
astrand "at" cendio.se
Wed Dec 22 21:49:00 2004
On Wed, 22 Dec 2004, James Weatherall wrote:
> > 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.
No pseudo-SecurityType messages are needed to enable the Tight encoding;
it's just a matter of sending a normal SetEncodings message with Tight
enabled. In this case, the problem is actually local cursor support, which
does not have anything to do with SecurityTypes either. So I don't think
that looking for a TightVNC-specific SecurityType makes sense.
I guess we could use TightVNCs "capabilities". It would allow dynamic
pixel format changes against RealVNC 3.X servers, but I'm not sure if it's
worth the troubles. The TightVNC vncviewer4 doesn't support capabilities
at all, currently.
> If you report the problem to the TightVNC developers then I'm sure they
That would be me. I'm the only TightVNC developer actively working on the
TightVNC vncviewer4, currently.
> > 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?
No, it's no bug. I've committed a patch that changed this behaviour
yesterday. I think it makes much more sense to start in fullcolor mode.
Peter Estrand Chief Developer
Teknikringen 3 www.cendio.se
583 30 Linkvping Phone: +46-13-21 46 00