Vine Server wakes display

Running Vine Server 2.2 on 24" iMac Alum with 10.5.1.

I notice if the display is asleep (not the Mac itself, just the display) and you connect to the Vine server the display wakes up. As I am at a remote location I guess there is no need for the display to wake - is there any way to avoid this, or is it a bug or possible feature request perhaps?

Ta.

ps.thx for the free server, it has been a godsend! And MUCH faster than Leopard’s own VNC server too. :smiley:

I believe this one of the limitations of VNC as it is more of a remote display type of program rather than a true terminal server.

Correct me if I am wrong as I would also be interested in having the local screen not enable while a user is remotely connected.

Fundamentally dk831 is correct; but in some situations Vine Server can behave as a terminal server.

If you launch a desktop server (The VS application not the System Server running as a service) and then Fast-User-Switch (even just back to the login window) then Vine Server will begin terminal serving that session.

In this situation I do think the screen will “wake up” but if it’s just at the login window it’s not as big a deal.

I’ll think about ways we might enhance Vine Server to keep the screen “dim”.

Well it has been over 6 years and I still see the same behavior.

If I start logged in and use a client to connect and switch to the login window, the console switches but I remain in my session. However, the screen does not go back off as long as I am doing something in the VNC session.

If I start at the login screen or logged in as another user and the display is asleep, the screen wakes up for almost exactly one second every time I type a key or move the mouse and then goes back to sleep! I can’t imagine it is that great on the display circuitry to have constant wake/sleep on the display like this, and in any case this is even worse than the display staying awake - imagine this happening at night in an office and attracting unwanted attention such as security.

It also isn’t great to have the display waking up at all - it can be a great security risk and/or annoyance as it alerts others that somebody is doing something on the machine. In some situations this is unacceptable. Other solutions such as finding ways to forcibly turn off the display won’t work either in situations where another user might be logged in, in which case we don’t want to disturb them (by forcing the display off) or might not be (in which case they might not restore the display settings when they leave the computer).

I don’t really understand why the screen is coming on at all; I was under the impression that by setting a non-standard port such as 5901 that a virtual session (like a Terminal Services thing) is being created separate from the session that the stock VNC server under OS X would create.

Any pointers on how to achieve this are appreciated, in the event that this problem has actually been solved since this thread was created. If not, I hope this will be fixed soon as this problem greatly limits the circumstances in which remote access to the machine is useful to me.

Thanks!

The port number has no bearing on how the screen is being served (Only on which port the communication is happening).

Typically when using the Fast User Switching/Terminal Services you WANT it on different ports so that different users can each reach their “User Session”. As to why the screen wakes up, you’ll have to ask Apple why events posted through the remote session API wake the screen, we don’t explicitly do so, but have found no way to suppress that inherent behavior.

[quote=“JonathanOSX”]The port number no bearing on how the screen is being served (Only on which port the communication is happening).

Typically when using the Fast User Switching/Terminal Services you WANT it on different ports so that different users can each reach their “User Session”. As to why the screen wakes up, you’ll have to ask them why events posted through the remote session API wake the screen, we don’t explicitly do so, but have found no way to suppress that inherent behavior.[/quote]

Thanks for fast reply! I assume by “they” you mean an engineer somewhere at Apple?

Yes, it’s an Apple behavior unfortunately.