Created attachment 28773 [details] metacity-transparency.png When I use either xcompmgr or metacity w/ compositing enabled, some windows don't have transparency. Its like they have a black background and the window contents are composited onto that. I will attach screen shots. My arch is i686, hardware is "Mobile Intel GM45 Express Chipset" in a Thinkpad X200. Noticed on the LVDS and VGA connector. Linux is 2.6.30.5 + tuxonice patches. Gentoo distro. This is Gentoo bug #281621. xorg-server-1.6.3, xf86-video-intel-2.8.0, mesa-7.5, libdrm-2.4.12. But I've observed this issue for about 1 year. Some software that demonstrate the issue are metacity's popup volume control window and avant-window-manager. Finally, I think the output from this python program is illustrative: $ ./icanhasedit.py hello.txt Traceback (most recent call last): File "./icanhasedit.py", line 351, in <module> d = Document (sys.argv[1]) File "./icanhasedit.py", line 325, in __init__ FrameWindow.__init__ (self) File "./icanhasedit.py", line 65, in __init__ self.set_colormap (self.get_screen ().get_rgba_colormap ()) TypeError: GtkWidget.set_colormap() argument 1 must be gtk.gdk.Colormap, not None Comes from: http://blogs.gnome.org/desrt/2008/08/11/icanhasedit/ First attachment shows metacity's volume popup which should be transparent.
Created attachment 28774 [details] fedora-transparency.jpg This is what it metacity's volume popup should look like. Captured on Fedora 11 on same hardware: for some reason, issue is not present there.
Created attachment 28775 [details] xcompmgr.png Here xcompmgr is used for compositing. Also have avant-window-manager which has a large black box instead of transparency.
Created attachment 28776 [details] dmesg-after_X.txt
Created attachment 28777 [details] Xorg.0.log
Does the same problem occur if you use the vesa driver on the system?
I didn't know vesa supported compositing. Will give it a try when I get a chance.
The logs don't indicate an obvious configuration error, but that is my gut feeling for this bug. If we can allocate 32bpp Visuals, as indicated by the PyGTK error, then we will not be able to do alpha compositing. However, the logs do suggest that 32bpp color depth is available. What does xdpyinfo say?
Unfortunately, I don't have Gentoo on this hardware anymore and I can't reproduce on Fedora (where it always worked). Will leave as needinfo, sorry.
Mass status change to NEEDINFO based on presence of NEEDINFO keyword. Please reopen if you can still reproduce the bug and are able to provide the information requested, thanks.
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.