UltraVNC viewer: 1.3.3 dev 10, 1.3.2, 1.2.4.0, etc.
vncserver: vnc4server 4.1.1+X4.3.0-37.6 (debian jessie)
Server OS: Debian GNU Linux (jessie)
Client OS: Windows 10 x64 (21H1)
Overview:
If UltraVNC viewer connects to vnc4server (in Linux) with 32 bit color depth, the blue component is lost from entire screen if the server is started with 32 bit color depth.
Steps to reproduce the issue:
1. Install vnc4server in debian jessie or wheezy (very old version).
2. Start vncserver in debian with
Code: Select all
vnc4server -geometry 1024x768 -depth 32Resulting screenshot with the issue:
Screenshot using TightVNC viewer (without the issue):
The cause:
I looked into this problem and found the cause. The bugs exist in both server and viewer sides. vnc4server offers pixel format bgr101111 if depth is 32. In this case, number of bits for red/green/blue are 11/11/10 bits respectively. In other words, it is necessary to send whole 32bit (4bytes) for each pixel. However, both server and viewer send/receive only 3bytes per pixel due to bugs. The bug comes from overflow in bitshift of redMax, greenMax, blueMax. These values are declared as unsigned 16bit int and signed 32bit int in viewer and server side respectively. Shifting-up blueMax by 22bit causes overflow in both side.
The following patch fixes this issue in UltraVNC viewer side. I built modified version of vnc4server and connected them, then, it was confirmed that the issue is fixed.
The patch which fixes the issue:
https://tyan0.yr32.net/files/vnc4server-patch.zip
However, vnc4server is not maintained anymore, so the bug will not be fixed. In addition, vnc4server is only provided up to debian jessie, which is no longer supported. I never see the other VNC server which uses such pixel format (bgr101111). So it is not worth enough to fix this issue also in UltraVNC side.
This post is just for your information.
Thanks.
P.S.
As for TightVNC (and also RealVNC ) viewer, it does not accept bgr101111 and requests rgb888 connection, therefore the issue does not happen.
