After waking the system from suspend to RAM (sleep function in KDE menu) the session is not immediately locked. It displays the user session for couple of seconds. See the following video.

http://www.youtube.com/watch?v=Jble0nh0fXA

I have tested it with both Simple screen locker and screen saver. What piece of KDE is responsible for that?

Qt: 4.8.4
KDE Development Platform: 4.10.1
kde4-config: 1.0

VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09)

The screen blanking functionality is integrated as part of KSMServer, the KDE Session Management process. It is also responsible for spawning the screen locker application which prompts you for your credentials.

Are you using compositing?

If you mean the "Enable Desktop Effects" the answer is yes.

I believe there was an or issue older bug report with a similar issue, but can;t find it.

Unfortunately this is something that KDE cannot guarantee - as the system initiates the suspend process virtually immediately before tasks such as locking the screen can be completed, or in certain instances initiated.

There is no method of fixing this in the immediate future.

If am not wrong be pressing the Sleep button on KDE's menu the first thing KDE does is to start the locking mechanism. I can see the screen being locked before the system suspends to RAM. Do you mean something different?

It is purely a timing issue as the process to lock the screen takes a few moments to initialize, however the sleep code issues the command to lock the screen and then the command for the system to enter sleep immediately afterwards, without waiting for the screen to finish locking.

Note: that may not be what is actually happening, it may be that another system broadcasts that the system is entering sleep, which triggers KDE to lock the screen.

Isn;t possible for the sleep code to poll the status of the screen locker before continuing? If the process to suspend to RAM is issued by a KDE subsystem would it be trivial to: Start screen locker, wait for the locking process to complete (by polling or via a signal issued by screen locker), continue and give the suspend signal ?

The current code does not support that. As a result of this being discussed with the developers though, they're going to investigate possible ways to fix this issue however.

Thanks you very much for you time you devoted to explain it.

I think I should issue a bug/feature report though to help other users etc.