I can confirm this happens in Gnome as well.

Is there any way that vnc-server can be made to act on the remote mouse in the
same way as the local mouse when it comes to mouse movements when powersave is on.
i.e.  a local mouse movement immediately kicks the machine out of powersave and
you either return the screen to normal behaviour or it asks for a password. If
the remote mouse via vnc moves then this should give the same behavour but it
does not - it does nothing.

Also I note that now for vnc-server running on fully updated fc5 machines the
behaviour is the same as in fc6.

Mike

There is a workaround to enable access to the server and see the screen even if
the server monitor has gone into powersave - 
1) Use F8 to bring up the vnc menu on the client.
2) Click Ctrl on the vnc menu which will allow ctrl to be sent to the server.
(ctrl is now ticked in the vnc menu
3) With the vnc menu dismissed do Alt-F3 to go to a text console and then Alt-F7
to return to X - in this process the monitor wakes up.
4) Now you have access to the server monitor screen in the normal way.
5) Before using the system get the vnc menu back with F8 and unclick ctrl

I tried reproduce this bug but I wasn't successfull. I tried set my gnome
screensaver after 1 minute and display shutdown after 2 minutes. I waited,
vncviewer became black. I tried move mouse and all works ok. Could you please
write me where can I set something bad?

Hi Adam

I am using KDE on both server and client - maybe that is the difference?

Mike

It's possible this is compiz related.  My PC is running beryl.  I set the window
manager back to metacity and allowed it to go into screensaver mode with the
monitors powered down and I was able to VNC in correctly.

I am not using compiz - but this is tested in KDE with three different servers
and three different clients and the error is consistent.  It is important to
wait until the usually green (power) light on the server machine monitor goes
yellow (or amber) to indicate that it is in powersave - and then connect -
anytime from this moment on the client cannot move the mouse on the vnc server
machine - for all the combinations of computers I have tried this on - and this
is the same for any fc6 kernel.

In fact this is also the case for my vnc servers running fc5 with a fully up to
date system.  The KDE screensaver is configured via the control centre ->
Appearance and Themes -> Screensaver and selected to start after 5 minutes (or
any other value)

In my case I have the control centre->Peripherals->Display set with Display
Management enabled under the Power Control tab.

(In reply to comment #6)
Yes, this is problem between vnc & compiz. Could you please view bug #214446 and
tell me if you have same problems? (and which server are you using - vino/native
Xvnc)

(In reply to comment #7)

Could you tell me which servers you use? If this problem is with different
servers looks that problem is in kde power-management (likewise with gnome all
works fine - comment #6)

What I meant is that the problem was seen using three physically different
computers but all the vnc clients are running fc6 fully up to date, and the vnc
server machines are all physically different but are running either fc5 or fc6
fully up to date. In each case the vnc server is started by including a "Load
vnc" line the module section in xorg.conf so that the vnc server starts as soon
as X starts after boot.

I hope this clarifies the detail.

(In reply to comment #9)

> I hope this clarifies the detail.

Yes, this is very important information for me. But I can't reproduce this bug
yet. I tried it with my up2date FC5 installation (vnc). I think this bug can't
be only in kde (I'm using gnome). But I'm going to test it with kde... Could you
write me which screensaver you're using, please? Thanks much for information

I set the screensaver to "random" and this happens no matter which screensaver
is running on the server machine - 

By the way I have just checked that the problem still occurs with the latest
version of VNC (vnc-4.1.2-9.fc6) running on both client and server using one of
the combinations of hardware, and both machines running KDE, both machines fully
up to date with the latest kernel.  The server machine has been running after a
reboot about 4 hours ago and had gone into screensaver and then into powersave
so that its screen was showing blank correctly.  I then ran vnc over the ssh
tunnel into that machine from my machine here - and it connected fine with an
initial blank screen showing correctly on the client running KDE.

Moving the mouse on the client did not wake up the server monitor (as before)

Going across to the server machine and waggling its mouse does wake up the
monitor, and then if I vnc into that machine from the client then then normal
mouse operation through vnc occurs.  Of course at this point the server is not
in powersave and its monitor and mouse action are normal.

This is exactly the symptoms that were seen previously and there is no change
with the latest version of vnc.

I have a colleague who also uses KDE and there is also a screensaver related
problem when using vnc into a server machine running FC4 with KDE. He chose not
to report his case since he was using an older version of Fedora for the server
machine.

Please note that the vnc connection is via an ssh tunnel although it would
presumably not be any different if not running in a secure tunnel?

(In reply to comment #12)

Och, I thought that you have black screen in vncviewer and you can't view
server's desktop. Of course that server's monitor stands in powersafe mode. Why
you want wake it? You want view desktop throught vnc, so no argument to wake up
server's monitor. This is not a bug, this is feature (correct behavior). If I
don't understand correctly I'm going to reopen this bug. I'm closing like NOTABUG

Of course it is needed to wake up the server monitor sometimes - for example if
one is doing maintenance remotely and the remote user is not available to wake
up his/her monitor then let's say we might want to alter a KDE setting which can
only be done with the desktop visible? Before we could make such alterations
then it is necessary to wake up the monitor so that in vncviewer we can see what
is happening at the remote (server) machine, surely?

I have needed this quite regularly for remote maintenance - and perhaps others
have this need also?

Just to be clear - when the server monitor is in powersave mode and showing a
black screen then the vncviewer also cannot see the screen - not in KDE anyway.
It is fine for the server machine not to wake the monitor up but if the
vncviewer cannot see the screen either then it IS a problem.

I would be quite happy not to wake up the monitor on the server screen provided
the vncviewer could still see the contents of the desktop - but it cannot do so
at least when KDE is used.

By the way - in your tests were you able to see the desktop of the server
machine in vncviewer even when the monitor on the remote (server) machine was in
powersave and black ? If so then you have not seen the same effect as for the
cases that I am reporting. In my case in this situation I cannot see anything on
the vncviewer window at all, and I can only work with the desktop if the remote
machine comes out of powersave.

After big testing I've reproduced this bug so I'm reopening it.

Excellent, thanks Adam - I was beginning to think that I was the only one seeing
this !

I have just tested this bug for a vnc server machine running FC6 with the latest
updated system and the client running FC5 with KDE as both desktops.  The
problem is no longer present for these machines.  I do not know what the
resolution has been but I note that there have been recent updates to xorg.   I
will test vnc for this problem again later today using machines running FC6 for
both client and server, and will report back on the results.

I have now tested for a vnc server machine running FC6 and a vnc client running
FC6 and the problem is not present.  

I am therefore closing this bug as resolved even though I don't know which
updated component resolved this bug.

I am presuming that the resolution may have occurred after the most recent
xorg-X11-server updates though I have no direct evidence for this.

Really interesting solution...

Sorry Adam - I thought that since the problem has gone away I should close this
- even though I did nothing specific to solve it!  Did you want to investigate
further to find what made the problem vanish?

One other thing that I have discovered is that even though on the vnc server
machine where the monitor remains firmly with powersave enabled and therefore
has its screen blank, on the client machine which is viewing remotely the screen
is now viewable with working mouse actions, even though the physical monitor on
the remote machine is still blank.  This is the correct behaviour. i.e. the
server machine can be used and changes to the desktop made which was the problem
previously.

So vnc is behaving properly now for the first time in a long while! 

One final comment - I suppose because the server machine still does not have the
monitor wake up from powersave then the original reported issue is technically
still present - but this does not matter at all if the system is now accessible
at the vnc client machine which was the original difficulty. So the previous
problem in using the machine remotely has now been removed and is in fact a
better solution than actually waking the physical monitor up.