Created attachment 34837 [details] GEdit screenshot showing black pixels instead of transparent Description: Xvfb shows wrong colored (e.g. black or grey) pixels instead of transparent when 8-bit color depth is set. I tested this case on x86_64 Arch Linux 2009.08 with xorg-server 1.7.5.902-1. Also I can confirm this bug at x86_64 Ubuntu 9.10 with xorg 1:7.4+3ubuntu7 and xvfb 2:1.6.4-2ubuntu4.1. Steps to reproduce (for Arch Linux 2009.08, other Linux distros would feature similar sequence): Open terminal and issue following commands: export DISPLAY=:1 Xvfb :1 -screen 0 640x480x8 & openbox & x11vnc -display :1 -bg -nopw -listen localhost Open another (!) terminal and issue: vncviewer localhost You can see new VNC viewer window on the screen. Right-click the mouse somewhere within blank area of that window. In the drop-down menu select Editors -> GEdit, and you will see the picture similar to one in attached file. Note that should you change 'x8' to 'x16' snippet in Xvfb command above, GEdit look become normal.
Can also confirm it on i686 Arch Linux with xorg-server 1.8.1-1.
(In reply to comment #1) > Can also confirm it on i686 Arch Linux with xorg-server 1.8.1-1. And on 1.9.0 too! Why there are no options in bugtracker to report versions higher than 1.7.5?
This is a bug for Xvnc, not Xvfb. Not our bug.
Created attachment 52373 [details] Corrupt GEdit window when Xvnc not involved
(In reply to comment #3) > This is a bug for Xvnc, not Xvfb. Not our bug. Excuse me, you are not right. Even when Xvnc is not involved in the case, the GEdit window is corrupt. The following command sequence would illustrate this: Xvfb :1 -screen 0 640x480x8 & gedit --display :1 & xwd -display :1 -root -out image.xwd convert image.xwd image.jpg As you can see, there are no any Xvnc calls there. You can open image.jpg in your favorite viewer and see GEdit window corrupted. I have attached image.jpg to this bug report.
Oh, yeah... 8bit is not very well supported in general. I can reproduce problems using your steps (although my results are differently broken). Xfake isn't useful for comparison because it crashes at starup when you request 8bit mode. 16bit works. Why are you trying to use 8bit?
(In reply to comment #6) > 16bit works. > > Why are you trying to use 8bit? I am building an application server with VNC access, so I'd like to minimize the network traffic. 8bit is sufficient for my needs and consume much less traffic than 16bit mode do.
Then why are you not using Xvnc?
(In reply to comment #8) > Then why are you not using Xvnc? I am using both x11vnc+Xvfb and Xvnc to test which of these configurations is better for production release. There are no corruptions in 8bit mode in Xvnc, but it would be nice that this bug be fixed in Xvfb too :)
Xvfb is not really "the future" ... Hopefully in the next couple years, kdrive, Xnest, and Xvfb will be removed and the Xorg DDX + xf86-video-nested or xf86-video-dummy will take their place in the same way that Xvnc is now an Xorg DDX driver instead of a separate DDX. I'm going to close this as WONTFIX unless you want to provide a patch to address this.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.