Bug 37074

Summary: (ATI Mobility M4 r128) xscreensaver screen corruption
Product: [Retired] Red Hat Linux Reporter: Alfredo Ferrari <alfredo.maria.ferrari>
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED WONTFIX QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-08-16 03:14:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
X configuration file
none
X log file none

Description Alfredo Ferrari 2001-04-22 16:43:58 UTC 
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
Comment 1 Mike A. Harris 2001-04-23 04:57:54 UTC 
Please attach your Xfree86 logs and configuration file with the create 
attachment link below.
Comment 2 Alfredo Ferrari 2001-04-23 16:05:15 UTC 
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.
Comment 3 Alfredo Ferrari 2001-04-23 21:11:54 UTC 
Created attachment 16145 [details]
X configuration file
Comment 4 Alfredo Ferrari 2001-04-23 21:13:16 UTC 
Created attachment 16146 [details]
X log file
Comment 5 Alexei Podtelezhnikov 2001-04-23 21:35:12 UTC 
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.
Comment 6 Alfredo Ferrari 2001-04-24 19:31:41 UTC 
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.
Comment 7 Mike A. Harris 2001-08-16 02:13:32 UTC 
*** Bug 45931 has been marked as a duplicate of this bug. ***
Comment 8 Mike A. Harris 2001-08-16 03:14:18 UTC 
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?
Comment 9 Mike A. Harris 2002-02-09 01:40:47 UTC 
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.