Created attachment 23556 [details] Xorg.0.log from Jaunty, with 6.11.0 -ati [Problem] Compiz exhibits problems running on this R100 card, including graphical glitches, no borders, etc. This is a regression since Hardy, where -ati 6.8.0 worked properly, and 6.9.0 when the problem first began. It is still seen with the 6.10.x and 6.11.0 drivers. [lspci] 00:00.0 Host bridge: Intel Corporation 82845 845 [Brookdale] Chipset Host Bridge (rev 04) Subsystem: IBM Device 0220 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] Subsystem: IBM Device 0517 [Original Report] I'm using a Thinkpad T30 with a builtin Radeon Mobility M7 LW [Radeon Mobility 7500] card. When upgrading to the Intrepid release candidate, almost everything worked except compiz. There were apparently no borders, and there were several graphical glitches. For instance, gnome-terminal was all white. I'm using the radeon open source driver which has worked flawlessly in Hardy. Tracking the problem, compiz --replace gave the following: /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x30005f1 to texture That message repeated forever. This happened in 16bit color depth, 1024x768. When I tried 24bit, there were no visual problems anymore, only everything running really, really slow. My card has only 16 MiB of VRAM, so the probable explanation there is that compiz can't handle the textures at that color depth. 800x600x24 worked, but I would rather use metacity than a 800x600 compiz. In the #compiz IRC channel, I together with a few compiz developers successfully confirmed the bug on a Gentoo machine running Xorg 6.9.0 and a similar card, though with 32MB of ram. The conclusion we came to is that between Hardy and Intrepid there has been a regression in the radeon driver that borked the 16bit mode. This wouldn't be a problem for people running cards with more memory than 16MB since they can switch to 24bit depth. The bug also exists in the exact same form on the latest LiveCD. Steps to reproduce: 1. Use a Radeon Mobility M7 LW [Radeon Mobility 7500] with 16 MB of VRAM 2. Switch to 16 bit mode (24bit is the default) 3. Restart X This bug is important since it affects -all- owners of Thinkpad T30 laptops, as well as other owners of the M7 card. The bug still exists in jaunty alpha. This is the logfile for the most recent alpha release. Note that I manually had to change to 16-bit depth for compiz to even start. With 24-bit depth compiz fails some checks and reverts to metacity.
Created attachment 23557 [details] glxinfo
Output from running `compiz --replace`: Checking for Xgl: not present. Detected PCI ID for VGA: Checking for texture_from_pixmap: not present. Trying again with indirect rendering: Checking for texture_from_pixmap: present. Checking for non power of two support: present. Checking for Composite extension: present. Comparing resolution (1024x768) to maximum 3D texture size (2048): Passed. Checking for Software Rasterizer: Not present. Checking for nVidia: not present. Checking for FBConfig: present. Checking for Xgl: not present. /usr/bin/compiz.real (core) - Warn: SmcOpenConnection failed: Could not open network socket /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (resizeinfo) - Warn: Bind Pixmap to Texture failure /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (resizeinfo) - Warn: Bind Pixmap to Texture failure /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (wall) - Error: Couldn't create cairo context for switcher /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (wall) - Error: Couldn't create cairo context for switcher /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (wall) - Error: Couldn't create cairo context for switcher /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (wall) - Error: Couldn't create cairo context for switcher /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x1800046 to texture /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x30005f1 to texture /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x1800046 to texture /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x30005f1 to texture The last two messages repeat forever.
Created attachment 23562 [details] [review] Possible fix Does this patch fix the problem?
Michel: I would love to test the patch (I'm the original launchpad reporter), is there a good way to test this under Ubuntu Intrepid? Jonathan
(In reply to comment #4) > Michel: > > I would love to test the patch (I'm the original launchpad reporter), is there > a good way to test this under Ubuntu Intrepid? you can follow my instructions here: http://www.botchco.com/agd5f/?page_id=2 before you build, apply the patch: patch -p1 -i radeon-depth16-aiglx.diff
I've built debs with this patch here: http://people.ubuntu.com/~bryce/Testing/ati-bug290359/
Okay. I downloaded the drivers from git, applied the patch, compiled and installed. Then I tried everything, even rebooting, but even then I saw no change. The exact symptoms remain. Jonathan
Hej, I'm experiencing this problem, too, and can confirm that the "Possible fix" DOES NOT help. In 16bit, still getting the Warn: No GLXFBConfig for depth 32 when running fusion-icon and switching to compiz with the help of that. No further error messages, but window decorations are completely missing (although some fading effects seem to work). While using 24bit, everything runs fine, but performance is really slow :( I'm using ArchLinux and compiled xf86-video-ati-git with the proposed patch (and of course installed it after removing xf86-video-ati and ati-dri). My card (lspci output): 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02) So, is there anything I can test/patch/provide so you can try to fix this issue? By the way, for me this is a regression, too, since Compiz used to work with 16bit and acceptable performance.
Created attachment 23726 [details] [review] add double buffered 32 bit visual Maybe compiz wants a double buffered visual. Does this patch help?
Nope, the second patch did not help, unfortunately. By the way, I found out that using 24bit improves watching youtube videos with the non-free flash plugin. So I'm torn between 16bit and 24bit ;)
What xservers did you use with 6.8.0 vs. 6.9.0+? I think it is probably related to aiglx changes in X rather than the driver since the visual setup code in the driver hasn't changed between 6.8.0 and newer versions.
Yes, that's possile. Unfortunately I did not track the compiz regression since I have not been using compiz for that time. But I remember the last time I used compiz was before the upgrade to X 1.6.x (the HAL stuff is a good memory aid;) So, is there any way to debug this without recompiling like hell ;)
(In reply to comment #12) > Yes, that's possile. Unfortunately I did not track the compiz regression since > I have not been using compiz for that time. But I remember the last time I used > compiz was before the upgrade to X 1.6.x (the HAL stuff is a good memory aid;) > So, is there any way to debug this without recompiling like hell ;) > If your distro provides older xserver packages you could try those.
(OT: How can I quote some comments?) Well, it does not really (excepte recompiling the old packages and when I'm thinking of the changes from 1.5->1.6...), I'm using ArchLinux... Is there any other way?
From what I have deduced by asking around in irc channels (specifically, #compiz, #ati and #radeon) the problem is in the GLX code in Xorg and not in the ati drivers. I was told to talk to Kristian Hoengsberg, xorg glx developer, but haven't done so yet. Phew, I miss compiz right now, haven't been able to use it for the past four-five months...
Created attachment 24209 [details] [review] Likely fix This Mesa patch seems to fix the problem here. Can you confirm?
I applied the patch and compiled the library, and noticed a change from the previous symptoms, but is not working, now I have window decorations but everything else, including desktop, is white. I tried reducing the screen resolution and didn't help, also rebooted the computer.
(In reply to comment #17) > I applied the patch and compiled the library, and noticed a change from the > previous symptoms, but is not working, now I have window decorations but > everything else, including desktop, is white. Do you still get any messages from compiz, e.g. about not being able to bind windows to textures?
Which version of Mesa should the patch be used against? I tried the latest dev version, but that one won't compile (unrelated error) Jonathan
(In reply to comment #19) > Which version of Mesa should the patch be used against? I created it against mesa Git master. > I tried the latest dev version, but that one won't compile (unrelated error) What's the 'latest dev version' you're referring to? What's the error? Does the patch not apply to the version of Mesa you're using?
Mesa-7.5-devel-20090313 was the version I used. This is the relevant part of the error: make[5]: Entering directory `snip/Mesa-7.5-devel-20090313/src/gallium/winsys/drm/intel/gem' make[5]: *** No rule to make target `default'. Stop. I got the download from here: http://www.mesa3d.org/beta/ Now I just found the git version as well, was really not obvious that there was one :) I will try compiling again.
(In reply to comment #21) > make[5]: Entering directory > `snip/Mesa-7.5-devel-20090313/src/gallium/winsys/drm/intel/gem' > make[5]: *** No rule to make target `default'. Stop. FWIW you don't need to build any Gallium stuff for this, try something like make GALLIUM_DIRS='' as a quick workaround.
Hi I am compiling against version 7.2 that comes with ubuntu intrepid, I had to manually apply the patch because this specific version was reporting a parameter count error and an undefined msaa_samples_array, which is part of the extra parameters that I had to remove, according to the current definition of driCreateConfigs, Instances like: driCreateConfigs(GL_RGB, GL_UNSIGNED_SHORT_5_6_5, depth_bits_array, stencil_bits_array, depth_buffer_factor, back_buffer_modes, back_buffer_factor, msaa_samples_array, 1); became: driCreateConfigs(GL_RGB, GL_UNSIGNED_SHORT_5_6_5, depth_bits_array, stencil_bits_array, depth_buffer_factor, back_buffer_modes, back_buffer_factor); to match the current definition. compiled ok and I am not receiving the texture error anymore, instead I am receving the following warning: /usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format could this be the root cause?
(In reply to comment #23) > /usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 > image format > > could this be the root cause? No, that's a harmless warning from the compiz video plugin, which you probably don't need anyway.
Omar, can you attach the glxinfo output with and without the patch applied?
Created attachment 24302 [details] glxinfo with the original distribution libraries
Created attachment 24303 [details] glxinfo with the opatched and rebuilt libraries glxinfo output added
Maybe there were more issues in Mesa 7.2... can you try the patch with 7.4?
I'm sorry, I don't have the environment to fulfill all the dependencies to build mesa 4, not sure if someone else can give it a try
Installed jaunty beta, to confirm that the error was still present in Mesa 7.4, applied the patch with same previous modifications and can confirm that the patch works, applying the tailored version of the patch solved the issue
Fixed in mesa Git and cherry-picked to the 7.4 branch, thanks for testing.
Created attachment 24596 [details] glxinfo with latest mesa git per 04/06/2009 I downloaded the latest git, compiled and installed. For me the bug stils persists. The attached glxinfo shows that I'm using the mesa devel version. How can I make sure that I really am using the mesa version that I installed? Bottom line: Bug isn't fixed as far as I can see Jonathan
(In reply to comment #32) > I downloaded the latest git, compiled and installed. For me the bug stils > persists. The attached glxinfo shows that I'm using the mesa devel version. > How can I make sure that I really am using the mesa version that I installed? grep _dri /var/log/Xorg.0.log Did you restart X after installing the self-compiled radeon_dri.so?
I just verified /usr/lib/dri/radeon_dri.so with the ./lib/radeon_dri.so in the freshly compiled git tree with md5sum and they match. Yes, I restarted X. I also checked the source code I compiled and saw that the patch has indeed been applied to my source tree. Very strange indeed as the patch fixes the problem for Omar Servin but not for me. I'm running out of ideas... Jonathan
(In reply to comment #34) > I just verified /usr/lib/dri/radeon_dri.so with the ./lib/radeon_dri.so in the > freshly compiled git tree with md5sum and they match. Yes, I restarted X. > I also checked the source code I compiled and saw that the patch has indeed > been applied to my source tree. > Is the xserver successfully loading the new 3D driver for AIGLX?
Created attachment 24604 [details] [review] Xorg log Yes, as far as I can see AIGLX successfully loads radeon_dri (I attached Xorg.log just to be sure) Sorry for spamming bugzilla with my silly questions. Jonathan
(In reply to comment #34) > Very strange indeed as the patch fixes the problem for Omar Servin but not for > me. I'm running out of ideas... Are you both running the same version of the X server? I suspect there might have been something else preventing this from working in 1.5...
My current versions: Server version: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.24-23-server i686 Ubuntu Radeon driver version: (II) Module radeon: vendor="X.Org Foundation" compiled for 1.6.0, module version = 6.12.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0
X.Org X Server 1.5.2 Release Date: 10 October 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.24-24-xen i686 Ubuntu Current Operating System: Linux bordslykta 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 Build Date: 26 March 2009 03:47:28PM xorg-server 2:1.5.2-2ubuntu3.1+ppa2 (buildd@rothera.buildd) This is using Ubuntu Intrepid. I will try the Ubuntu Jaunty betas as soon as I get home from my vacation, will be afk for more than one week starting today. Jonathan
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.