session-lock: fix potential race

Currently the session lock client has no 100% safe way to know when it
is safe to suspend after requesting that the session be locked.

For a suspend to be safe the compositor must have either blanked or
rendered a lock surface on all outputs before suspending. This is
because the current framebuffer on suspend appears to be saved and
displayed again after suspend, at least on my Linux system.

If a new "locked" frame for all outputs is not rendered before suspend,
an "unlocked" frame or frames will likely be briefly displayed on resume
before the lock surfaces are rendered or the screen is blanked.

To fix this, wait until a lock surface has been rendered on all outputs,
or if that times out until all outputs have been blanked, before sending
the locked event to the client.

Resolving this race on the compositor side without protocol changes
is the most effective way to avoid this potential information leak,
regardless of which session lock client is used.

0 files changed, 0 insertions, 0 deletions