Red Hat Bugzilla – Bug 107114
ATI Mach64 forgets option "panel_display"=off after some time (DPMS?)
Last modified: 2007-11-30 17:10:32 EST
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
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):
(--) ATI(0): ATI 3D Rage Mobility graphics controller detected.
(--) ATI(0): Chip type 4C52 "LR", version 4, foundry TSMC, class 0, revision 0x01.
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
LCD is on and shows garbled image. LCD will stay on afterwards.
LCD should still be off
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:
command=/usr/X11R6/bin/X -layout CRT vt7
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,
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