Red Hat Bugzilla – Bug 91799
Analog Output: screen blanking drops signal
Last modified: 2005-10-31 17:00:50 EST
Description of problem: Using the radeon driver, all signal output to an analog monitor is dropped when screen blanking is enabled. This occurs even when DPMS is disabled. Also, any DPMS state drops all signals to the screen, hsync + vsync, in no particular order. Note: the opposite is true for the digital output: the screen is blanked, but backlight NEVER turned off. Version-Release number of selected component (if applicable): XFree86 4.1, 4.3, 4.3.99-4 How reproducible: 100% Steps to Reproduce: 1. Using a computer with an ATI M6D chip (Compaq N410C, for example)... 2. xset -dpms; xset s blank; xset s 1; LCD will blank, but leave on backlight; external (analog) LCD backlight will go off. [This is actually a serious problem for us, which I can discuss privately]. 3. xset dpms 2 3 4; Internal LCD backlight remains on; external off. Actual results: External monitor always goes to power-off; internal never. Expected results: Both screens should behave as instructed. Additional info: Tried the latest XFree86 snapshot (4.3.99.4)... one changelog reference seemed relevant... problem persists... also tried on RH 9.0... same issue. I also played with various "clonemode" settings... no change.
Please attach your XFree86 config file and log file, as text files only, and as attachments, not in the comments sections. Also, please paste the output of /var/log/messages to a text file and attach it.
Created attachment 92029 [details] XF86Config file XF86Config file... one of many. Note: requires xset s blank && xset s <time> to see issue.
Created attachment 92030 [details] XF86 log file I didn't include /var/log/messages as there were no Xserver messages (or any other relevant messages).
Relevent files attached.
There is no XFree86-Servers in RHL 8.0 or 9, reassigning to "XFree86".
The backlight is not controlled by XFree86 at all. That isn't a bug, it just isn't a feature supported by the radeon driver in XFree86 yet. When ATI or someone else submits a patch to add that feature to XFree86, and it gets included in a future release of XFree86, it will eventually make it into a future release of Red Hat Linux as well. For now however, this is not a bug, as it is not supported by the driver.
According to the Man page, DPMS is supported, so the internal display should power-off. Regardless, blanking the screen shouldn't drop signal to an external screen.
You are using a home brew custom built XFree86, and a home brew custom kernel. That is not supported. We support only the binaries that we ship with the OS. You may wish to seek support and/or report your problem on http://bugs.xfree86.org and the xfree86@xfree86.org mailing list.
The logs sent were the last version tried... I created this problem using RH 9.0, stock kernel & stock XFree86 (I did run up2date after install). (I did mention this in my report). The problem also occurs on stock 7.3 (XFree86 4.1). I haven't tried 8.0 (4.2).
Created attachment 92077 [details] Patch to RADEONBlank - comment out turning off hsync & vsync when blanking. Note: I also entered a report (and submitted this patch) to xfree86... http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=320 --------- I don't suggest that this is a permanent fix... but it solves my immediate problem. Was there a reason that HSYNC and VSYNC were dropped when blanking the screen? I also noticed while debugging the issue that the DPMS code is never, ever called, no matter the monitor, settings, etc. DPMSInit IS called... but the radeon DPMS power state code is never called. This may have bearing on the reports of issues with Radeon and DPMS, in general.
This issue is fixed in Fedora Core 2. Setting status to "CURRENTRELEASE". If this issue turns out to still be reproduceable in the latest version of Fedora Core, please file a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates.