Bug 86204

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.

Also please indicate specifically how you are starting up 2 separate
X sessions, as that my be important information.

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!

Created attachment 90624 [details]
X config file

Created attachment 90625 [details]
X log file

Log file for display :0.

Created attachment 90626 [details]
X log file

X log file for display :1.

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?

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 ***

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.

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....

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.

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.

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.