From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 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 bgr233 either. Version-Release number of selected component (if applicable): 4.0-5 How reproducible: Always Steps to Reproduce: 1. start vncserver -depth 24 on machine A 2. run vncviewer on machine B to look at A 3. Actual Results: Too few colours (notably green instead of pale gray :-() Expected Results: 256 colours, and no green tinge (as in earlier versions) Additional info: 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: -pixelformat format 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. Thank you!
Please, try to reproduce this bug with latest version in FC5
closing, fc3 isn't supported now