Consider support for Intel KVM AMT (porotocol version 4.0) about turbovnc HOT 8 CLOSED

I can confirm that "-colors 256" does the trick. The colors seem to be messed up, but it's good enough for console access.

from turbovnc.

The "not documented anywhere" part is the problem with this. The last open source version of RealVNC was 4.1.2, and all subsequent versions (including the newer viewer that apparently supports this extension to the spec) have been closed source. The only way to support this would be to get the hardware in house and snoop the protocol. Even then, I'd have to be cautious of potentially stepping on patents or running into other legal issues from back-engineering something that isn't open. I am extremely disinclined to do that, and even if I were inclined, it would need to be done in the context of a paid contract. I am not going to donate labor to work around issues caused by for-profit companies who don't know how to play nice with the rest of the VNC community. Closing as wont-fix until/unless that situation changes, but thanks for documenting the workaround.

from turbovnc.

Completely understandable, thanks for your reply and for the work/support with TurboVNC.

from turbovnc.

Just one more note, in case you want to support it some day for one of your clients:
The Open MDTK project (used to manage Intel AMT) can configure one of 3 clients for VNC access: RealVNC, UltraVNC, TightVNC. I assume they all 3 implement the same protocol.

The same Open MDTK tool can act as a local proxy to do some VNC signaling (which I don't understand) to connect to an alternate Intel AMT port 16994.
https://software.intel.com/en-us/blogs/2013/01/09/opendtk-commander-with-vnc-kvm-to-redirection-port

And some more info:
https://scivision.co/intel-amt-vpro-full-remote-kvm-control-without-proprietary-realvnc-viewer-plus/

Maybe you can get Intel to sponsor your development efforts :-)

from turbovnc.

Those viewers don't implement the same protocol. RealVNC v4 implements RFB v3.8, as does TigerVNC. Apparently the newer RealVNC versions implement their proprietary RFB v4.0. UltraVNC and TightVNC both implement v3.8t (3.8 with Tight extensions), and TurboVNC implements v3.8t as well. So you should use whatever settings you would normally use for the TightVNC Viewer, and those should work with TurboVNC.

from turbovnc.

Did I understand you correctly that you can configure the server to accept TightVNC clients? Have you tried doing that and seeing whether if fixes this issue?

from turbovnc.

You can't really configure anything on the server. The Open MDTK client (that runs on Windows) has an option to configure and launch one of 3 clients: RealVNC, UltraVNC, TightVNC. I have only tried RealVNC, not the other 2. It may just be that it simply starts the other 2 in 8-bit color mode.
Given that the protocol is not documented and that TurboVNC client works in 8-bit color mode, I don't think it's worth spending any more time on this. I initially thought that maybe there was some trivial improvement that could be made to the TurbVNC client but that doesn't seem to be the case.

from turbovnc.

There probably is a trivial improvement that could be made, but not without knowing what the RFB v4.0 protocol is doing.

from turbovnc.