How do I blank the server screen???

Bill_ITPro · Post by **Bill_ITPro** » 2004-09-22 20:05

I need to have the server screen blank so that when one of our workers is doing something remotely that others shouldn't see they can't. Can someone assist please? Thanks

B

NightRyder · Post by **NightRyder** » 2004-09-23 00:53

.. theres this button.. maybe you should look for it.
It hides up in the tool bar.
It's called "Toggle Remote Imput and Remote Monitor Blank (On/Off)"
It looks like a mouse with a red slash across it. When it's enabled, the slash is an x, and the remote monitor and input are disabled.

Bill_ITPro · Post by **Bill_ITPro** » 2004-09-27 18:28

Yes I have seen it since I posted Thanks. The problem it that it doesn't completely blank out the remote system's desktop it flashes on and off. Any ideas why?
Thanks again

Bill

Post by **Rudi De Vos** » 2004-09-27 19:13

Black screen is accomplisched by the power manager.
We tell the system to put the video output in sleep mode.

But, when you move mouse or press a key, the system try to activate the video back.
After each input, we tell the system, keep in sleep mode.

Together with the video card, we also tell the monitor to go in standby.

-If your system does not have a monitor that can be put a sleep
-You have a system that very fast wake from sleep mode

Bill_ITPro · Post by **Bill_ITPro** » 2004-09-28 20:23

Thanks for the reply and btw to state the obvious UltraVNC kicks arse!

S33k3r

ACN · Post by **ACN** » 2004-10-07 15:02

Hi,

But, when you move mouse or press a key, the system try to activate the video back.
After each input, we tell the system, keep in sleep mode.

Hmm, that doesn't sound very optimal? First of all, this might just allow someone to "glimpse" something they shouldn't have seen, secondly it will prevent any actual "saving" of the attached monitor (if any), seeing as it will be repeatedly taken in and out of "sleep" mode (something which for some monitors might cause even more stress than just leaving them on!) Nor will there be any powersaving to be had (from allowing the display adaptor to "sleep", if supported), as this too will be woken up all the time (again, possibly cause a greater power usage than if left on).

Is there any chance that someone will look into making this work better? (Which sould be possible, even if it might only be practical with some restraints, such as only when running with the video-hook driver and/or having disabled inputs etc.)

I imagine that it will necessary to either A) find some way of preventing mouse and screen changes from "reaching" the part of windows that will cause a "wakeup" to occur, B) find a way to blank the monitor that isn't related to (or influenced by) the normal "power managment" functions, or perhaps C) somehow modify the video-hook driver, so as to allow it to fully function as a display-adaptor / monitor pair (under the assumption that if all mouse movement / screen changes take place on the video-hook "display", windows will have no reason to wake up the other (physical) monitor, or at least that is the theory?)

Or perhaps the easist solution would simply be to have the server show a full-screen, always-on-top, blank (all-black) window, when this option is enabled? Although this does nothing towards "saving" the monitor, it should solve any security issues relating to the screen not being properly blanked.

Well, just my 2 cents anyway.

Regards,

ACN.

Post by **Rudi De Vos** » 2004-10-07 16:29

True,
RFB=Remote frame buffer.

1) black window --> remote==black, copy of the video buffer
2) You can not block the server complete, else in case of network disconnection you have a black screen that can not be restored.
3) Local input blocking is not the only problem, the remote
input also wake the powersaver.
4) Video card is already put in standby mode (signal to monitor is cut, but video card keeps running)

I'm open for all idea's, but the only way i have found is using the power managment with the flashing problem.
Screen blanking is pure R&D, and not documented...any help
is always appriciated

+Video card in standby, if you put it a sleep, remote==black
+Monitor in sleep mode

Probs:
1) monitor does not support sleep mode -> flashing
2) The latency to wake (LCD) is faster then we can put it back
a sleep-> flashing

Guest · Post by **Guest** » 2004-10-07 19:37

[quote="Rudi De Vos"]True,
RFB=Remote frame buffer.

1) black window --> remote==black, copy of the video buffer
2) You can not block the server complete, else in case of network disconnection you have a black screen that can not be restored.
3) Local input blocking is not the only problem, the remote
input also wake the powersaver.
4) Video card is already put in standby mode (signal to monitor is cut, but video card keeps running)

I'm open for all idea's, but the only way i have found is using the power managment with the flashing problem.
Screen blanking is pure R&D, and not documented...any help
is always appriciated

+Video card in standby, if you put it a sleep, remote==black
+Monitor in sleep mode

Probs:
1) monitor does not support sleep mode -> flashing
2) The latency to wake (LCD) is faster then we can put it back
a sleep-> flashing[/quote]

Hi Rudi!

Wow that was fast! (my first posts in this forum, so I obviously didn't expect such fast response, and certainly not from a developer, which I can gather you are, if not THE developer *blush*)

Well, I'm not an expert in these matters (although I do code for a living, so I'm not totally ignorant either), but I will attempt some further comments:

(Please let me know if you find my posts too verbose/long? While it is a bit of a general problem I have, I could possibly try harder to restrain myself, if you prefer shorter, less elaborate responses?)

The problem with the screen being left blank in case of (unexpected) disconnection should be solvable. On the top of my head:

- The server should be able to "detect" such a dead connection (some kind of timeout when no further packets are recieved. If necessary some kind of simple "ping" or "keep alive" packet could be implemented in the viewer to ensure that the only cause of extended periods of no reception is actually a closed/crashed viewer).

- If so, the server could simply remove the blanking and re-enable the inputs.

- If this is somehow not possible or practical to implement, I'd suggest using a (very small) seperate util for doing the actual screen-blanking (possibly the input-locking too), which the server will run (or activate). This util could then check for, say, keyboard inputs and take apropriate action (ie. remove the blanking, or at least do so if the server doesn't object or whatever?)

The problem with monitors going on and off (revisited):

- Once again, it is my opinion that this feature, at least as long as it works as it does now, should either be removed or at least accompanied by a warning/disclaimer in the documentation/readme. This, as mentioned before, because such repeated entering and leaving of the "sleep" mode might well have undesireable sideeffects (added wear & tear on the monitor for one.) aside from giving users a false sense of security. (But of course, you DO mention that it is an experimental and thus unsupported feature, so...)

Some ideas for solutions (free from my imagination, might not work or be doable at all):

- Might it be possible to somehow "hook" into the windows powermanagment system, and take (more or less) control over it, so as to be able to change its behaviour with regard to what will cause a wakeup (ie. force it to ignore mouse and keyboard events while the server has clients connected)?

- Alternatively, could the VNC server post its keyboard and mouse events in such a manner as to bypass the powermanagment system? (Possibly this could be done in combination with the above, such that the server "tags" such events, while the PWM hook ensures that such "tagged" events are ignored. This would also differentiate between input from VNC and from the actual hardware keyboard/mouse.)

- Like you mention with the blanking issue, some of these schemes might possibly have the side effect of leaving the server in some kind of "unusable" state if something goes wrong with VNC (server or client side), such as leaving the input locked or the monitor blanked, with no way of disabling it again (locally), aside from rebooting the machine. While this would be of concern to some users, it is entirely possible that other users would actually prefer this to the alternative, namely that the input and monitor might NOT be locked/blanked when they should be (if you have security concerns, you might prefer the occasional reboot to even a slight chance of someone getting to see or do something they shouldn't!) This is just to say that even a solution with such problems might have a lot of merrit, as long as it is clearly stated what might happen in these cases. (I for instance, mainly use UVNC to manage my fileserver. Since no input/output devices are usually connected anyway, I wouldn't mind if there was a chance of these being accidentially and permanently locked. In fact I probably wouldn't notice, as I would need to do a power-cycle in order to connect a keyboard to it anyway).

- While this might be the most promising suggestion of mine, it is probably also the one that will require the most coding to implement (and the one that is most difficult for me to explain in few words):

I imagine that the "video-hook driver" could be expanded to actually act as if it were a real display adaptor (ie. making windows think a secondary display was connected to the machine), there might be a quite elegant solution to this problem (and possibly several other issues as well). Now, I wouldn't know if this is at all possible or how difficult it would be to do, but let's assume it can be done for the sake of argument:

First of all this would mean that VNC could (would?) have its very own desktop (depending on how Windows is configured to handle multiple adaptors/monitors), which might be useful for other reasons (at the very least it would resolve any problems caused by flawed display adaptor hardware and drivers, and possibly allow the VNC driver to be the only display driver installed on no-monitor systems).

Secondly, and more relevant to the topic at hand, I am guessing that Windows is "smart" enough to only wake monitors/adaptors that are actually being updated (ie. I'm assuming that, in a multi-monitor setup, only the monitor on which your mouse is currently moving, will be awoken by powermanagment?) If this is actually the case, all the "blanking" problems should be solved automatically this way, as the server could easily prevent the client from moving the mouse outside the screen provided by the driver (which would be the only one visible in the viewer anyway).

Regards,

ACN.