Description of problem: vnc.so : VNC viewer blocked when dpms becomes active on the server side. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. You would need a aystem with Quadro FX370 card (10de:040a), using nv or nvidia's driver. 2.Setup xorg with vnc, as described at - http://kbase.redhat.com/faq/docs/DOC-7097 3. Connect to vnc server 3. Let dpms kick-in, on the vnc server Actual results: display is not updated on vnc client Expected results: display should update on vnc client Additional info: The remote vnc viewer window is not updated anymore when the local workstation's screen power saver mode becomes active (first timeout of the standby/suspend/off modes reached). Once the dpms timeout is reached (not the screen saver timeout!) the remote vnc viewer session remains blocked (no framebuffer update anymore) until the (local) workstation's mouse or keyboard generates new local input events. A tcpdump trace (attached) confirms that a framebuffer request is sent by the client and well ACK'ed but the framebuffer update is never replied back despite several key and pointer events from the viewer well received by the server. The failure happens too with recent nvidia driver (nvidia-185.18.29-1.x86_64), and with nv driver and latest vnc-server-4.1.2-14.el5_3.1 package installed but NOT when using vesa driver, or with other graphics card like ATI ES1000, ATI FireGL or NVIDIA GeForce2 for example.
I have the same problem with RHEL 5.3 (Tikanga). If I connect to the VNC server then open a terminal then $ xset dpms force standby $ /bin/echo -e '\a' $ /bin/echo -e '\a' $ /bin/echo -e '\a' $ xset q ... DPMS (Energy Star): Standby: 1200 Suspend: 1800 Off: 2400 DPMS is Enabled Monitor is in Standby ... After the xset command the screen goes black as expected. I blindly type the three echo commands from the vnc client and the server machine beeps each time but the screen stays black the entire time. Hitting a key on the server's keyboard or moving the server's mouse restores the display with all the commands already on the screen. Nothing is hanging, everything works normally except that moving the mouse and hitting keys in the vnc client can't take the monitor out of standby as "xset q" shows. This happens both in kde and gnome. $ cat /proc/driver/nvidia/version NVRM version: NVIDIA UNIX x86_64 Kernel Module 177.70.22 Sun Nov 9 20:00:58 PST 2008 GCC version: gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) $ cat /proc/driver/nvidia/cards/0 Model: G94 IRQ: 74 Video BIOS: 62.94.90.00.0d Card Type: PCI-E DMA Size: 40 bits DMA Mask: 0xffffffffff Bus Location: 0f.00.0 vnc and X server versions: vnc-server-4.1.2-14.el5_3.1 (x86_64) xorg-x11-server-Xorg-1.1.1-48.76.el5 (x86_64) Sounds a lot like this other bug that was never really fixed: https://bugzilla.redhat.com/show_bug.cgi?id=213931
Workaround: If you're using kdm you can workaround by editing file: /usr/share/config/kdm/kdmrc and adding "-dpms" to the "ServerArgsLocal" in the "Core config for local displays" section. ServerArgsLocal=-dpms If you're using gdm you might need a different workaround as X server options are hardcoded. https://bugzilla.redhat.com/show_bug.cgi?id=451562
Turns out I need to turn off the screen saver entirely with the command below to avoid all problems. Ok for me since this machine is on a KVM and I never leave it on the monitor when I leave. ServerArgsLocal=-dpms -v -s 0
Created attachment 417206 [details] Possible patch (untested yet) Based on this post http://www.realvnc.com/pipermail/vnc-list/2009-March/059694.html I wonder if this patch would help in this case. What this patch does is to set DPMS on whenever a remote keyboard or pointer event is received.
The patch sounds very promising but I downloaded the source rpm for vnc and it says "Building Xvnc and the VNC support for native X servers is much more complex". Here are the package versions on my system. vnc-4.1.2-14.el5 (x86_64) xorg-x11-server-Xorg-1.1.1-48.76.el5 (x86_64) I guess all I need is a new libvnc.so? I'd be glad to test it but don't have the time to figure out how to build it.
I built test packages for x86_64 platform, they are available on http://people.redhat.com/atkac/vnc/. Can you please download & test them?
It's not fixed but it's better. Here's what I did from VNC. # xset dpms force standby ; xset q DPMS (Energy Star): Standby: 1200 Suspend: 1800 Off: 2400 DPMS is Enabled Monitor is in Standby # xset q // this command is typed blindly on black screen DPMS (Energy Star): Standby: 1200 Suspend: 1800 Off: 2400 DPMS is Enabled Monitor is On // We can see the Monitor is now "On" instead of "in Standby" because // of the keys we typed but the screen is still black. // This is an improvement due to the patch! # xset s reset // this command is typed blindly on black screen // this resets the screen saver and I can see again // never tried the 'reset' command before so not sure this workaround is new. // It seems like in the locations where the patch turns on the monitor, that // if it also reset the X screen saver we would be all set.
Created attachment 421772 [details] Updated patch including screensaver code Another possible patch, now also including a reset of the screensaver.
The patch code looks very promissing. Would it be possible to create an x86_64 test package as Adam Tkac did in Comment #6 [vnc-server-4.1.3-2.el5.1.x86_64.rpm] I do not have a build environment for the Xserver but I can reproduce the bug easily.
(In reply to comment #9) > The patch code looks very promissing. Would it be possible to create an x86_64 > test package as Adam Tkac did in Comment #6 > [vnc-server-4.1.3-2.el5.1.x86_64.rpm] > I do not have a build environment for the Xserver but I can reproduce the bug > easily. Sorry for late response. Test packages are available on http://people.redhat.com/atkac/vnc/5.6-test (4.1.2-14.el5_5.3 version).
It works perfectly thanks! Tried it in the kdm login screen after restoring the unhacked /usr/share/config/kdm/kdmrc and in the kde environment after restoring power management in the screen saver settings. The version number on this package was lower than on the previous one you gave me so had to use the --oldpackage option. I'm sure you knew that but just thought I'd mention it.
(In reply to comment #18) > It works perfectly thanks! Thanks for your positive feedback. > The version number on this package was lower than on the previous one you gave > me so had to use the --oldpackage option. I'm sure you knew that but just > thought I'd mention it. Yes, I did this intentionally. Official update (distributed via RHN) will have higher version than the second test package but lower version than the first test package. Now you can safely run the second test package and it will be automatically updated to the official one.
Let me know if I should submit a new ticket for the following: I am seeing the same problem from vncviewer; although, my system "says" that the DPMS extensions are not present. Yet, after about 30 min my display goes blank (note: I have already disabled the screensaver). Particulars: Red Hat Enterprise Linux Client release 5.5 (Tikanga) VNC Server Enterprise Edition E4.5.4 (r41964) - built Jun 14 2010 09:46:36 Graphics card: nvidia Quadro FX 570 I too am running VNC Server in "service mode" (vnc.so) on my Linux system and connecting via vncviewer from my Window XP laptop. The connection is established without incident. The problem is that if my display has entered sleep mode (or whatever mode it's entering), then I can't wake it up from the vncviewer. Even though my system reports that the DPMS extensions are not present, it sure acts as if the DPMS extensions _are_ present (or some similar functionality is present). I tried the workaround of setting "ServerArgsLocal=-dpms -v -s 0" in /usr/share/config/kdm/kdmrc but it didn't make any difference. Therefore, something is apparently turning off the display but I have no idea what.
(In reply to comment #20) > Let me know if I should submit a new ticket for the following: > > I am seeing the same problem from vncviewer; although, my system "says" > that the DPMS extensions are not present. Yet, after about 30 min my > display goes blank (note: I have already disabled the screensaver). > > Particulars: > Red Hat Enterprise Linux Client release 5.5 (Tikanga) > VNC Server Enterprise Edition E4.5.4 (r41964) - built Jun 14 2010 09:46:36 > Graphics card: nvidia Quadro FX 570 > > I too am running VNC Server in "service mode" (vnc.so) on my Linux > system and connecting via vncviewer from my Window XP laptop. The > connection is established without incident. The problem is that if my > display has entered sleep mode (or whatever mode it's entering), then I > can't wake it up from the vncviewer. > > Even though my system reports that the DPMS extensions are not present, > it sure acts as if the DPMS extensions _are_ present (or some similar > functionality is present). I tried the workaround of setting > "ServerArgsLocal=-dpms -v -s 0" in /usr/share/config/kdm/kdmrc but it > didn't make any difference. > > Therefore, something is apparently turning off the display but I have no > idea what. Can you please tell me which graphics driver do you use? Also please tell me if you are able to wake up the machine from DMPS standby when you move the mouse attached to the computer (or by pressing key on the attached keyboard).
Thanks for your reply! (In reply to comment #21) > Can you please tell me which graphics driver do you use? Also please tell me if > you are able to wake up the machine from DMPS standby when you move the mouse > attached to the computer (or by pressing key on the attached keyboard). /proc/driver/nvidia/version NVRM version: NVIDIA UNIX x86_64 Kernel Module 169.12 Thu Feb 14 17:51:09 PST 2008 GCC version: gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) As a reminder, my system claims it doesn't have the DPMS extensions; although it behaves as if it does. To answer your question, Yes. I can wake up the machine if I move the mouse or press a key on the peripherals attached to the computer. As an update, I put the following in the xorg.conf file and it seems to have successfully disabled the video standby mode: Section "ServerFlags" Option "AIGLX" "on" Option "blank time" "0" Option "standby time" "0" Option "suspend time" "0" Option "off time" "0" Option "Xinerama" "0" EndSection Via a web search I saw a reply saying to do the above. Now in general standby mode is disabled, except if I lock the display and the unlock it via my password. It seems that after the unlock procedure the screensaver blanking gets re-enabled. To workaround that, I have to remember to do an 'xset s off' after unlocking the display.