Bug 86204 - DPMS settings require key press to take effect on different displays
DPMS settings require key press to take effect on different displays
Status: CLOSED DUPLICATE of bug 73733
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-17 02:58 EST by Reid Rivenburgh
Modified: 2008-01-17 12:49 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:52:12 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 config file (4.50 KB, text/plain)
2003-03-17 10:51 EST, Reid Rivenburgh
no flags Details
X log file (29.17 KB, text/plain)
2003-03-17 10:53 EST, Reid Rivenburgh
no flags Details
X log file (29.59 KB, text/plain)
2003-03-17 10:54 EST, Reid Rivenburgh
no flags Details

  None (edit)
Description Reid Rivenburgh 2003-03-17 02:58:35 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

Description of problem:
This is a fairly obscure bug that's been in every version of XFree86 that I've used.

I normally run gdm on display :0 and a separate session on :1.  I switch back
and forth between them using the ctrl-alt-fn keys.  The :0 display has very
small DPMS values (15/30/45 seconds), since I want the monitor off when it's
just sitting at the login prompt.  The :1 display has large (normal) DPMS values.

Here's the bug: When I've been working on :1 and switch to :0, if I don't press
any keys, the DPMS settings from :1 remain in effect.  As soon as I press a key
(like shift), the :0 DPMS settings kick in.  It seems to me that this key press
shouldn't be necessary.  It's a very minor annoyance, but I thought I'd report it.


Version-Release number of selected component (if applicable):
XFree86-4.2.99.902-20030220.1

How reproducible:
Always

Steps to Reproduce:
1. See above.
2.
3.
    

Additional info:
Comment 1 Mike A. Harris 2003-03-17 09:51:23 EST
You haven't provided enough details to be able to troubleshoot the problem
area (assuming there is a bug in the code).

Attach your X server log and config file as individual file attachments,
indicating what hardware you have, what drivers you're using, wether it is
a laptop or not, wether APM is in use or not.

I will need to be able to reproduce this after I receive your info, to
determine if it is a bug or not, and try to debug it.
Comment 2 Mike A. Harris 2003-03-17 09:53:03 EST
Also please indicate specifically how you are starting up 2 separate
X sessions, as that my be important information.
Comment 3 Reid Rivenburgh 2003-03-17 10:50:47 EST
Okay, sorry about not providing enough details.  I kind of assumed it was
independent of drivers and easily reproducible.  (I know, foolish....)

This is not a laptop.  I have an nVidia GeForce 2 MX type of card that is hooked
up to an LCD monitor via DVI (though I'm sure it was happening with a CRT
monitor, too).  I'm using nVidia's drivers, version 1.0.3123.  I'm not using APM.

I start in runlevel 5, so gdm is started automatically on :0.  I added the
following lines to /etc/X11/xdm/Xsetup_0 to modify X settings:

/usr/bin/X11/xset b 2 300 400
/usr/bin/X11/xset dpms 6 12 30

(I don't know why now I'm changing the bell....)

I manually start my second X session on :1, from vt1, with "startx -- :1".  In
my .xinitrc flie, I set DPMS like this:

xset +dpms 250 500 750

I'll also attach my log and config files after this.

Thanks.  I hope this isn't some stupid little error on my part after all!
Comment 4 Reid Rivenburgh 2003-03-17 10:51:55 EST
Created attachment 90624 [details]
X config file
Comment 5 Reid Rivenburgh 2003-03-17 10:53:01 EST
Created attachment 90625 [details]
X log file

Log file for display :0.
Comment 6 Reid Rivenburgh 2003-03-17 10:54:04 EST
Created attachment 90626 [details]
X log file

X log file for display :1.
Comment 7 Mike A. Harris 2003-03-17 14:02:33 EST
Ok, let me state the problem you're describing how I see it based on the
information you've supplied:

You start up X on display :0 with a quick DPMS setting.  Then you start up
another X server instance on display :1 with longer time delay before DPMS
kicks in.  You keep working on :1 beyond the DPMS timeout on :0, and at some
point you switch from :1 to :0 with CTRL-ALT-Fn and when it switches over,
DPMS remains turned on with :0 which you've just switched to from :1, until
you press a key to de-activate DPMS.  Does that sound accurate?

Comment 8 Mike A. Harris 2003-03-17 14:04:54 EST
Section "Device"
	Identifier  "Videocard0"
	Driver      "nvidia"
	VendorName  "Videocard vendor"
	BoardName   "NVIDIA GeForce 2 MX (generic)"
EndSection


You are using unsupported 3rd party video drivers and not using
the supported Red Hat supplied video drivers.


*** This bug has been marked as a duplicate of 73733 ***
Comment 9 Reid Rivenburgh 2003-03-17 14:37:15 EST
I know this is currently marked resolved, but to clarify what's happening based
on comment #7:

"You start up X on display :0 with a quick DPMS setting.  Then you start up
another X server instance on display :1 with longer time delay before DPMS
kicks in."

Correct.

"You keep working on :1 beyond the DPMS timeout on :0, and at some
point you switch from :1 to :0 with CTRL-ALT-Fn and when it switches over,
DPMS remains turned on with :0 which you've just switched to from :1, until
you press a key to de-activate DPMS."

I'm not sure about this last part.  What you describe could be the actual
problem, which hadn't occurred to me.  What I see when I switch from :1 to :0 is
the normal gdm login screen, with the monitor on, of course.  When I hit a key,
something is reset so that DPMS kicks in after a few seconds and turns the
monitor off.  I guess the X server might have thought that the DPMS was on and
the monitor was off when I first switched to :0, even though the monitor is
obviously on.  Is that your conjecture?  My assumption was that the DPMS
settings from :1 were somehow being carried over to :0, which I don't actually
know to be the case.  I guess if I switched from :1 to :0 and never hit a key
and it never turned off the monitor, then your theory would be correct.  I bet
that's right.  Maybe the fix in that case would be to disable the DPMS counting
mechanism on a VT switch away, and enable and reset to zero on a VT switch to.

Regarding the nvidia drivers....  I have in the past used the stock XFree86
driver, and I vaguely remember this problem happening then, too.  Unfortunately,
I'm not in a position to test that right now.  I will later and report back if so.
Comment 10 Reid Rivenburgh 2003-03-18 01:28:25 EST
Well, after a lot of messing around, I finally was told to use "Option
"FlatPanel"" to get my DVI/LCD combo to work with the nv driver.  Unfortunately,
DPMS doesn't seem to work.  Executing "xset dpms force off" makes the screen
freeze, but the monitor doesn't go off.  That makes it pretty much impossible to
test.  I guess I'll go back to my nvidia drivers and we'll let this bug slip off
into the RESOLVED night....
Comment 11 Mike A. Harris 2003-03-18 01:50:06 EST
I sympathise with the problem you're experiencing, however assuming it is
a driver bug of some kind, there isn't anything that can be done about it
from our side of the fence directly to solve the problem, since we do not
have Nvidia's technical specifications nor any knowledge of how their
hardware works.

It is unfortunate, however for the "nv" driver, we rely on Nvidia to
directly fix bugs in the driver, and add whatever support to it that they
are willing to add.

About all we can do is wait until any given bug just happens to get fixed
in some future update of the driver.  I do monitor the CVS development,
and I do backport fixes that I encounter, as well as investigate patches
that turn up publically.  However there generally isn't any way for us
to actually debug Nvidia hardware problems and fix them ourselves and
supply our fix upstream.  We rely on upstream directly for Nvidia related
fixes.

Again, this all applies to the "nv" driver only.  The proprietary
"nvidia" driver we don't have any way of supporting whatsoever.
If you do however track down a patch or bugfix, or more information,
feel free to update the report.  If something turns up that may fix
the "nv" issue, I can investigate it at least.  Sorry I can't be of
more assistance.
Comment 12 Reid Rivenburgh 2003-03-18 01:59:06 EST
I understand completely, and I appreciate your time.  When I submitted this bug
report, I thought it was minor but easy to reproduce.  It has since blown up
into quite a mess!  I'll keep an eye out for the DPMS-related issues and report
back if I have something useful to add.  Thanks again.
Comment 13 Red Hat Bugzilla 2006-02-21 13:52:12 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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