Bug 137529 - DPMS power off not norking on IBM Thinkpad 600e
DPMS power off not norking on IBM Thinkpad 600e
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-29 05:40 EDT by Joachim Frieben
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-06 19:53:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
X.Org X11 6.8.1 configuration file (3.29 KB, text/plain)
2004-10-29 05:46 EDT, Joachim Frieben
no flags Details

  None (edit)
Description Joachim Frieben 2004-10-29 05:40:36 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020 Epiphany/1.4.4

Description of problem:
For the current Fedora development tree, DPMS is not working properly
on an IBM Thinkpad 600e. The chipset is a Neomagic NM2200 [MagicGraph
256AV]. DPMS is enabled in the 'xorg.conf' file and reported to be
active, as verified e.g. by typing 'xset -q'. Having executed 'xset
dpms 0 0 10', the display should power off after 10 seconds.
For an attached external monitor LG1710B, the screen turns blank after
10 seconds, but the status LED remains green, whereas it should turn
orange. The same result for various display set-ups, where either the
internal or external displays or both simultaneously are used. Using
different monitor sections specified as "externdisp" and "interndisp"
has not effect on the DPMS functionality as well (although switching
displays with customized screen settings works nicely). For some
popular Redmond OS, things behave as expected, so it's probably not a
hardware defect.

Version-Release number of selected component (if applicable):
xorg-x11-6.8.1-12

How reproducible:
Always

Steps to Reproduce:
1. Boot Fedora rawhide.
2. Change DPMS settings by typing 'xset dpms 0 0 10'.
3. Type 'xset -q' to verify that the settings have been changed
accordingly.
4. Wait 10 seconds to watch the display turn blank and the status LED
stay green.
    

Actual Results:  The display does not power off.

Expected Results:  The display should have powered off and the status
LED should have turned orange.

Additional info:

This never worked for FC2, but I am pretty sure that this worked for
some of the FC3 test releases, in particular FC3 test 1 and probably
FC3 test 3 as well.
Comment 1 Joachim Frieben 2004-10-29 05:46:57 EDT
Created attachment 105932 [details]
X.Org X11 6.8.1 configuration file
Comment 2 Joachim Frieben 2004-10-31 05:31:13 EST
DPMS of the external L1710B display is definitely working for FC1. For
the current FC3RC3 setup, changing the video driver from 'neomagic' to
'vesa' allows to recover the correct behaviour.
Comment 3 Joachim Frieben 2004-12-19 10:14:08 EST
Ok, there has been some progress on this issue. Running the "apmiser"
power saving daemon which is part of the (3rd party) "tpctl" utility
is responsible of disabling the "power off" capability completely. The
reported bug is apparently due to its interference with the DPMS
functionality of X. It is not obvious though which component to hold
liable for this, even a hardware problem may be at the origin of this
malfunction. Disabling "apmiser" restores the "power off" capability.
However, even then, the DPMS settings are not strictly respected, at
least as far as the timing is concerned. The monitor will definitely
go to "power off" mode after some time, but not necessarily the time
chosen through "xscreensaver" or by means of "xset dpms ..." in
contrast with the "vesa" driver functionality where things work
predictably.
Comment 4 Mike A. Harris 2005-03-06 19:53:05 EST
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue.  Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:

        http://fedora.redhat.com/download

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.

Setting status to "CURRENTRELEASE".

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