Red Hat Bugzilla – Bug 150804
vncviewer autoselects bgr222 instead of bgr233 on 8bit display
Last modified: 2013-04-30 19:33:14 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
My laptop (Omnibook 800CT) has a 256 color display.
If vncviewer is pointed at a 24-bit colour session, it chooses bgr222
(which looks nasty) rather than bgr233 (which produces acceptable
results even if it sometimes makes me wish I had a better display)
Vnc version 3.3.6 used bgr233, and tightvnc 1.2.9-3.1 also uses bgr233
In version 4.0 there doesn't seem to be a command line option to force
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start vncserver -depth 24 on machine A
2. run vncviewer on machine B to look at A
Actual Results: Too few colours (notably green instead of pale gray :-()
Expected Results: 256 colours, and no green tinge (as in earlier
Not running a wm (the laptop is meant to be a thin client)
This Xvnc option:
-pixelformat fmt set pixel format (rgbNNN or bgrNNN)
seems to do what you want.
I don't buy that. The server I'm connecting to (3.3.6) is running in 24 bit
mode, and it's man page says that bgr233 is the default:
Specify pixel format for server to use (BGRnnn or RGBnnn). The
default for depth 8 is BGR233 (meaning the most significant two
bits represent blue, the next three green, and the least signif-
icant three represent red), the default for depth 16 is RGB565
and for depth 24 is RGB888.
I need to select the pixel format in the viewer, not the server.
Having now checked, with vncserver version 4.0 using -pixelformat bgr233 forces
the server into 8bit mode (as opposed to setting a default for viewers).
I want the server to run in 24bpp so that when viewed from clients that can
handle it I get true colour.
This bug report is for the viewer: when viewing a 24bit session on a 256 colour
display it should either select bgr233 automatically (as tightvnc and older
versions of vnc do) or have an option to force bgr233.
So I'm reopening the bug.
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
Please, try to reproduce this bug with latest version in FC5
closing, fc3 isn't supported now