Bug 581478 - vnc.so : VNC viewer blocked when dpms becomes active on the server side.
vnc.so : VNC viewer blocked when dpms becomes active on the server side.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: vnc (Show other bugs)
5.5
All Linux
urgent Severity medium
: rc
: ---
Assigned To: Tim Waugh
qe-baseos-daemons
: ZStream
Depends On:
Blocks: 607562 607566
  Show dependency treegraph
 
Reported: 2010-04-12 07:27 EDT by ritz
Modified: 2013-10-02 07:05 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 607562 (view as bug list)
Environment:
Last Closed: 2013-10-02 07:05:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Possible patch (untested yet) (1.60 KB, patch)
2010-05-27 07:33 EDT, Olivier Fourdan
no flags Details | Diff
Updated patch including screensaver code (1.47 KB, patch)
2010-06-07 06:13 EDT, Olivier Fourdan
no flags Details | Diff

  None (edit)
Description ritz 2010-04-12 07:27:06 EDT
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.
Comment 1 Francois L'Archeveque 2010-04-21 17:13:54 EDT
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
Comment 2 Francois L'Archeveque 2010-04-22 11:23:24 EDT
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
Comment 3 Francois L'Archeveque 2010-04-30 11:37:30 EDT
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
Comment 4 Olivier Fourdan 2010-05-27 07:33:05 EDT
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.
Comment 5 Francois L'Archeveque 2010-05-27 17:53:38 EDT
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.
Comment 6 Adam Tkac 2010-05-28 06:01:08 EDT
I built test packages for x86_64 platform, they are available on http://people.redhat.com/atkac/vnc/. Can you please download & test them?
Comment 7 Francois L'Archeveque 2010-05-28 16:13:35 EDT
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.
Comment 8 Olivier Fourdan 2010-06-07 06:13:44 EDT
Created attachment 421772 [details]
Updated patch including screensaver code

Another possible patch, now also including a reset of the screensaver.
Comment 9 Francois L'Archeveque 2010-06-07 10:28:11 EDT
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.
Comment 17 Adam Tkac 2010-06-24 08:10:49 EDT
(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).
Comment 18 Francois L'Archeveque 2010-06-24 13:22:39 EDT
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.
Comment 19 Adam Tkac 2010-06-25 03:39:42 EDT
(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.
Comment 20 Mun 2010-07-26 18:53:40 EDT
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.
Comment 21 Adam Tkac 2010-08-02 08:21:50 EDT
(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).
Comment 22 Mun 2010-08-03 02:21:02 EDT
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.

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