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