Description of problem: On a laptop with ATI Mach64, the Option "panel_display"=off allows me to use a higher resolution (1280x1024) than the internal LCD can support. This works nicely, the LCD stays dark after starting XFRee86. However, after some time of idling/screensaving, the LCD comes back to life, showing a colourful but unhealthy-looking screen of garbage with bits from the external display (small wonder, it only has 1024x768 but the external image is 1280x1024). I have tried to turn off DPMS, but apparently Option "dpms" "off" has no effect, and it is seems to be turned on by default. Besides, DPMS is actually fairly useful, so turning it off for ever would seem a waste. Version-Release number of selected component (if applicable): XFree86-4.3.0-37 (--) ATI(0): ATI 3D Rage Mobility graphics controller detected. (--) ATI(0): Chip type 4C52 "LR", version 4, foundry TSMC, class 0, revision 0x01. How reproducible: Regularly, but takes unknown amount of time (5..20min) Steps to Reproduce: 1. Set up XFree86 with "panel_display"=off, restart XFree86 2. turn on screensaver 3. walk away Actual results: LCD is on and shows garbled image. LCD will stay on afterwards. Expected results: LCD should still be off Additional info: First experienced this in a combination with two XFree86 running on different consoles, one for external only at 1280x1024, and one for external+internal at 1024x768. Since then, I have reproduced this with only the "external" ServerLayout, so it looks unrelated.
Created attachment 95186 [details] XFree86 log file Bug appears with the following "gdm" configuration: [server-CRT] name=CRT server command=/usr/X11R6/bin/X -layout CRT vt7 flexible=true
I don't have access to any Mach64 laptop hardware to be able to attempt to reproduce this unfortunately. I recommend filing a bug report in XFree86 bugzilla for this issue at: http://bugs.xfree86.org and in your upstream bug report attaching your X server log file and config file to the report using bugzilla's file attachment feature. If you then paste the upstream bug URL here, I can track the issue upstream, and if it is determined to be a real bug in the X server or video driver and gets fixed, I can investigate backporting it for future erratum. Also, if you attach your X server log file and config file here, I will attempt to reproduce this on some non-laptop Mach64 hardware I have here, although I can only do that with a CRT display. Thanks in advance.
Filed upstream as requested, http://bugs.xfree86.org/show_bug.cgi?id=793 Thanks Jan
The upstream bug report is currently in "LATER" state. The driver maintainer has indicated that there might be a way to work around this issue by poking around in BIOS source, however there is not any fix available currently. Please upgrade to our currently supported Fedora Core 2 release, which uses X.Org X11 6.7.0. If the problem still exists in Fedora Core 2 with all updates applied, please file a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once the problem is resolved in X.Org CVS, it will be included in future X.Org releases, and make its way into a future Fedora Core OS release. Setting status to "WONTFIX" until this issue is fixed in X.Org official sources.