You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In file rfbproto.c, function InitialiseRFBConnection() libvncserver checks the RFB version sent by the server and calls DefaultSupportedMessagesUltraVNC() or DefaultSupportedMessagesTightVNC() depending on the received RFB version (3.4, 3.6, 3.14 or 3.16 for UltraVNC, 3.5 for TightVNC). However, the recent versions of the servers all report RFB version 3.8, so the server-specific capabilities are never set. This means, for example, that server-side scaling does not work anymore (because the capability is set in DefaultSupportedMessagesUltraVNC).
We need a new way of identifiying the servers - unsing the RFB version does not work anymore ...
The text was updated successfully, but these errors were encountered:
Added pull request #506 to fix this issue.
With this, UltraVNC and TightVNC servers are not recognized by the RFB version, but by their specific security types (rfbUltra and rfbTight).
In file rfbproto.c, function InitialiseRFBConnection() libvncserver checks the RFB version sent by the server and calls DefaultSupportedMessagesUltraVNC() or DefaultSupportedMessagesTightVNC() depending on the received RFB version (3.4, 3.6, 3.14 or 3.16 for UltraVNC, 3.5 for TightVNC). However, the recent versions of the servers all report RFB version 3.8, so the server-specific capabilities are never set. This means, for example, that server-side scaling does not work anymore (because the capability is set in DefaultSupportedMessagesUltraVNC).
We need a new way of identifiying the servers - unsing the RFB version does not work anymore ...
The text was updated successfully, but these errors were encountered: