I experimented some more with this suspend to ram business. I noticed some strange things.

If I am in X/KDE, in a Konsole session, use the chvt idea as many people have suggested, and then as root run my suspend shell script, when the screen resumes the Konsole screen fills with a bunch of carriage returns.

I discovered the chvt idea is unnecessary on my box anyway. Without that command I witness no spurious or additional carriage returns. I don't know why this idea is routinely suggested.

At one point in the tests all of my KDE hotkeys failed. I had to exit and restart X/KDE to restore the hotkeys. I could not repeat the problem, however.

If I suspend to ram from any non-X console session, the screen display does not restore. If I have an X session running, I can toggle to that session with Alt-F7 and all is well.

However, if no X is running and I suspend to ram, I cannot toggle to any console screen and see an actual display. I cannot blindly type startx and get a screen. Everything stays blank.

I found many online references about blank screen problems but found no solutions. The problem is not the nvidia drivers because the blank screen problem occurs without running X.

The only time I experienced no screen problems was while in X, not running chvt, and suspending to ram from a konsole session or the KDE Run command (using kdesu). Then the screen restored normally.

As an idea, I read that when restoring a suspend session, automatically running the screen saver lock might be a good precaution. I tried that at the end of the script (kdesktop_lock --forcelock). That did not work well because the shell script is run as root but the KDE session is owned by a normal user. Two different passwords. I then tried the screen saver lock using the sudo -u command and my login name. That did not work well either because when the screen saver ran I received a bunch of DCOP error messages.

Conclusion: wonderful possibilities but a lot of work remains to get suspend to ram to function smoothly.