There are two issues at work:
1. Vinagre doesn't seem to have a correct implementation of VeNCrypt, so
as is the case with the TigerVNC Server, it is necessary to disable any
VeNCrypt security types in the TurboVNC Server. Passing '-securitytypes
vnc,otp,unixlogin' to /opt/TurboVNC/bin/vncserver or setting
$securityTypes = vnc,otp,unixlogin in ~/.vnc/turbovncserver.conf or
/etc/turbovncserver.conf accomplishes that.
2. When multi-threaded Tight encoding is enabled, the TurboVNC Server
uses the four zlib streams available for Tight encoding differently than
when multi-threaded Tight encoding is disabled. A properly-implemented
TightVNC-compatible viewer should be able to handle both use cases, but
apparently Vinagre doesn't have a correct implementation of Tight
decoding, so it only handles the single-threaded use case. Passing
-nomt to /opt/TurboVNC/bin/vncserver or setting $numThreads = 1 in
~/.vnc/turbovncserver.conf or /etc/turbovncserver.conf works around the
issue.
Also, I strongly recommend enabling "Use JPEG Compression." The
performance will suck otherwise.
On 1/21/21 4:16 PM, Andrew wrote:
> I noticed that a TurboVNC server does not seem to be compatible with
> Gnome's Vinagre <
https://en.wikipedia.org/wiki/Vinagre> software. I've