Created attachment 19028 [details] Screen corruption while using compiz First, I apologize if there already is a bug for this. I looked, but I didn't see anything that caught my eye. I recently switched to using EXA (XVideo doesn't work under XAA, but that's another issue) and I discovered that OpenGL applications (glxgears, compiz-fusion, stepmania, etc) cause screen corruption. Exiting the OpenGL app and switching away then back to the X VT corrects the corruption. This doesn't happen under XAA, and I tried using "UnverifiedFeatures" (from reading another topic) but that didn't help. I'm using git sources, XOrg 7.4/1.5, Mesa 7.2 rc1, 2.6.26 kernel with gentoo patches
I'm seeing this on RS690 using openSUSE 11.0/Xserver 1.5/mesa,drm,radeonhd from git. What's your hardware?
try the following options and see if any of them help: Option "EXANoComposite" "TRUE" Option "EXANoUploadToScreen" "TRUE" Option "EXANoDownloadFromScreen" "TRUE"
I have a T60 with an ATI Radeon Mobility x1400 I tried those options, and different combination of them, with mixed results. When using Metacity compositing (and glxgears), EXANoUploadToScreen seems to help. I don't seem to get the font corruption any more, however I'm still frequently getting the colored horizontal lines (though not as often). EXANoComposite only seemed to slow it down. When using Compiz-Fusion, EXANoUploadToScreen and EXANoComposite seem to be the best. Again, I'm not seeing the font corruption, but I'm still getting the horizontal lines. With Compix-Fusion, using only EXANoUploadToScreen still gave me font corruption. EXANoDownloadFromScreen does nothing but give me unusable frame rates. Also, this might not be related, but in GNOME, I have a script that changes my background every 5 minutes. In playing with those options and switching between Metacity and Compiz (between xserver restarts), by background seemed to be changing more sporadically and sometimes a bg change would cause the corruption and sometime it would correct it. But it didn't do so in and pattern I could discern.
I don't use composite at all (Option "Composite" "False" in section Extentions). Option "EXANoDownloadFromScreen" cures the glyph rendering here, but the horizontal bars stay. Sometimes the screen flickers. I guess this is related to the chip used (isn't X1400/M54 of the same generation than X1250/RS690?). Btw. this happens since the dri merge some month ago, but I was just to lazy to report :-(
Matthew, could you please test the latest GIT code? There were some changes to the accel infrastructure which could have an influence on what you are experiencing.
I tested v1.2.3 on openSUSE 11.0/Xorg 1.4/Mesa 7.2. Hard to reproduce now, since system crashes when - moving the mouse while glxgears is running - switching to text console and back from login screen
I also tested version 1.2.2 - no crashes here, but corruption still exists.
With git master, the corruption appears to be gone. However, at some point between now and my previous post, I started experiencing the same problems that Marc described (system freezing when using OpenGL or switching VTs). I'm not precisely sure when this cropped up or if it was caused by an xserver/mesa/drm update or if it was a radeonhd problem. I fixed it by adding [Option "EXANoComposite" "True"] to my xorf.conf device section. But I should note that with the latest git, my [Option "EXANoComposite" "True"] solution now causes rendering corruption with scroll bars, but that is much more acceptable than OpenGL corruption.
I gave v1.2.4+ a try today. No more screen corruptions visible with EXA, even without "EXANo*" options. Also no crashes using glxgears. Only drawhack is, that glxgears fps is 320 with EXA and 650 with XAA. Can you confirm this, Matthew?
I just updated from git master. I am still seeing desktop rendering errors when using EXA+EXANoComposite. Problems include things like scroll bar corruption and discoloration, and sporadic text discoloration (some times rendered with out color). I'm also still getting lockups when usig EXA+Composit+OpenGL. And as noted in bug 18097, I'm still getting a bunch of warnings in my xorg log: (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY!
Hello: Your last comment was some time ago, maybe situation is much better now, hopefully this is even solved. Could you feedback with a recent graphics stack? Regards,
Does this issue occur with the preferred ati driver (xf86-vide-ati)? If so, please move this to the Driver/Radeon component. Development of radeonhd has pretty much halted and development focus is on the ati driver. Please see http://www.x.org/wiki/radeonhd If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.
I haven't noticed any issues with xf86-vide-ati + KMS.
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.