wayland_protocols::ext::session_lock::v1::server

Module ext_session_lock_v1

source
Available on crate features staging and server only.
Expand description

manage lock state and create lock surfaces

In response to the creation of this object the compositor must send either the locked or finished event.

The locked event indicates that the session is locked. This means that the compositor must stop rendering and providing input to normal clients. Instead the compositor must blank all outputs with an opaque color such that their normal content is fully hidden.

The only surfaces that should be rendered while the session is locked are the lock surfaces created through this interface and optionally, at the compositor’s discretion, special privileged surfaces such as input methods or portions of desktop shell UIs.

The locked event must not be sent until a new “locked” frame (either from a session lock surface or the compositor blanking the output) has been presented on all outputs and no security sensitive normal/unlocked content is possibly visible.

The finished event should be sent immediately on creation of this object if the compositor decides that the locked event will not be sent.

The compositor may wait for the client to create and render session lock surfaces before sending the locked event to avoid displaying intermediate blank frames. However, it must impose a reasonable time limit if waiting and send the locked event as soon as the hard requirements described above can be met if the time limit expires. Clients should immediately create lock surfaces for all outputs on creation of this object to make this possible.

This behavior of the locked event is required in order to prevent possible race conditions with clients that wish to suspend the system or similar after locking the session. Without these semantics, clients triggering a suspend after receiving the locked event would race with the first “locked” frame being presented and normal/unlocked frames might be briefly visible as the system is resumed if the suspend operation wins the race.

If the client dies while the session is locked, the compositor must not unlock the session in response. It is acceptable for the session to be permanently locked if this happens. The compositor may choose to continue to display the lock surfaces the client had mapped before it died or alternatively fall back to a solid color, this is compositor policy.

Compositors may also allow a secure way to recover the session, the details of this are compositor policy. Compositors may allow a new client to create a ext_session_lock_v1 object and take responsibility for unlocking the session, they may even start a new lock client instance automatically.

Structs§

Enums§

Constants§