From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.16-3smp i686) Whenever a screensaver starts on a Dell Latitude C800 with an ATI Mobility M4 (using the r128 drivers and with hardware acceleration on and working) it leaves after resuming normal operations the top 3-5 lines of the screen corrupted (mostly white with an irregular pattern) It occurs with all screensaver I tried up to now (ie Atlantis which was my default one) The corruption goes away if I log out from gnome as soon as the gdm screen reappears (I assume that X gets reinitialized) For what it matters the problem appeared or with XFree86-4.0.2-11 or with XFree86-4.0.3-3 which I downloaded from Mike Harris area (I really don't remember which one, however I am sure there was no problem with the initial 4.0.2-xxx release I got hardware acceleration working the first time) I assume it is a X problem but I am not sure at all. Running GL demos or tuxracer works nice with no screen corruption. The corruption occurs only when exiting the screensaver mode, I am running with backing store enabled if it makes any difference. Reproducible: Always Steps to Reproduce: 1.Start X 2.Start one of the (x)screensaver demos 3.Resume normal operations Actual Results: A few lines at the top of the Laptop display got permanently corrupted Expected Results: No screen corruption
Please attach your Xfree86 logs and configuration file with the create attachment link below.
Hi, thanks for the quick reply. I'll provide the XF86Config-4 file and the X logs as soon as I am back at home this evening (European time). Thanks.
Created attachment 16145 [details] X configuration file
Created attachment 16146 [details] X log file
From what I see, you use 1400x1050*16bpp (totaling 3Mb or so) on 16 Mb card. This is fine for 2D rendering. 3D acceleration requires a lot more memory. Can you reproduce this behavior with 1280x1024x16bpp or smaller? REmove all you 24bpp and 32 bpp entries too.
Hi Mike you are right. The problem is not there at lower resolutions (I tried up to 1280x1024). For the sake of curiosity, did anything changed between XFree86-4.0.2-9.xx/Mesa-3.4-9 and Seawolf which could justify some increase in videoram usage (as I told you I did not have the problem before upgrading to the latest releases)? Sorry for having bothered you.
*** Bug 45931 has been marked as a duplicate of this bug. ***
If you use DRI, wether or not any currently running app is using DRI, the X server needs to allocate RAM for doing DRI. If you crank your resolution and bit depth up, there is very little RAM left, and when something uses DRI, the DRI engine cannot get enough RAM for doing hardware acceleration. You must not run DRI if using ultra high resolution, or else lower res/depth. Does lowering res/depth fix this for you?
I'm closing the bug as fixed using lower resolution, since I believe the problem to be caused by using too high res and DRI not having enough RAM to operate correctly. I believe the X server itself should detect these situations and handle it cleanly on its own, but that is a major X design overhaul, and not really a minor bugfix. It's something we'll need to rely on future versions of XFree86 correcting.