Bug 91799 - Analog Output: screen blanking drops signal
Analog Output: screen blanking drops signal
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
i686 Linux
high Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-28 08:53 EDT by Michael Breuer
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-01 02:03:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
XF86Config file (15.27 KB, text/plain)
2003-05-28 12:31 EDT, Michael Breuer
no flags Details
XF86 log file (32.75 KB, text/plain)
2003-05-28 12:32 EDT, Michael Breuer
no flags Details
Patch to RADEONBlank - comment out turning off hsync & vsync when blanking. (1.42 KB, patch)
2003-06-02 09:54 EDT, Michael Breuer
no flags Details | Diff

  None (edit)
Description Michael Breuer 2003-05-28 08:53:16 EDT
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.
Comment 1 Mike Chambers 2003-05-28 09:18:07 EDT
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.
Comment 2 Michael Breuer 2003-05-28 12:31:59 EDT
Created attachment 92029 [details]
XF86Config file

XF86Config file... one of many.  Note: requires xset s blank && xset s <time>
to see issue.
Comment 3 Michael Breuer 2003-05-28 12:32:46 EDT
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).
Comment 4 Michael Breuer 2003-05-28 13:42:52 EDT
Relevent files attached.
Comment 5 Mike A. Harris 2003-05-28 15:53:56 EDT
There is no XFree86-Servers in RHL 8.0 or 9, reassigning to "XFree86".
Comment 6 Mike A. Harris 2003-05-28 15:56:43 EDT
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.
Comment 7 Michael Breuer 2003-05-28 17:47:45 EDT
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.
Comment 8 Mike A. Harris 2003-05-28 18:30:43 EDT
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.
Comment 9 Michael Breuer 2003-05-28 22:41:31 EDT
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).
Comment 10 Michael Breuer 2003-06-02 09:54:49 EDT
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.
Comment 11 Mike A. Harris 2004-10-01 02:03:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.