PhosphorWayland::SessionLock Class Reference

Client-side wrapper around ext_session_lock_manager_v1 / ext_session_lock_v1. More...

#include <phosphor-wayland/include/PhosphorWayland/SessionLock.h>

Inheritance diagram for PhosphorWayland::SessionLock:

Signals
void	locked ()
	The session is now locked; this client owns the lock and must call unlockAndDestroy() to release it.
void	finished ()
	The compositor will not (or will no longer) lock the session: the lock object has been torn down and the request is over.
void	lockedChanged ()
	isLocked() changed.

Public Member Functions
	SessionLock (QObject *parent=nullptr)
	~SessionLock () override
void	lock ()
	Request that the session be locked.
void	unlockAndDestroy ()
	Release the lock after a successful authentication: sends unlock_and_destroy and flushes.
bool	isLocked () const
	True between locked() and unlockAndDestroy() (or a compositor-driven finished()).

Static Public Member Functions
static bool	isSupported ()
	True iff the compositor advertises ext_session_lock_manager_v1.

Detailed Description

Client-side wrapper around ext_session_lock_manager_v1 / ext_session_lock_v1.

Requests that the compositor lock the session and observes the outcome: the compositor replies with either locked() (this client now owns the locked session and is responsible for authenticating and releasing it) or finished() (the request was denied, or an existing lock already owns the session). On a successful authentication the owner calls unlockAndDestroy().

This is the foundation primitive a lock service composes; it carries no authentication, no UI, and (deliberately) no lock surfaces. Per the protocol a real lock screen must create an ext_session_lock_surface_v1 for every output before the compositor presents the locked frame and sends locked(); that rendering layer is a shell concern wired in a later phase. Until surfaces are added the compositor decides, per its own policy and time limit, when (or whether) to emit locked().

Security guarantee (from the protocol): if the client dies while the session is locked, the compositor must NOT unlock. Accordingly this object never destroys a lock for which locked() was received without going through unlockAndDestroy(): a bare destroy in that state is a protocol error and would also defeat the guarantee.

Construct one per process. Threading: every method MUST be called from the GUI thread.

Constructor & Destructor Documentation

SessionLock()

PhosphorWayland::SessionLock::SessionLock ( QObject *  parent = nullptr )

explicit

~SessionLock()

PhosphorWayland::SessionLock::~SessionLock ( )

override

Member Function Documentation

finished

void PhosphorWayland::SessionLock::finished ( )

signal

The compositor will not (or will no longer) lock the session: the lock object has been torn down and the request is over.

Emitted at most once per lock().

isLocked()

bool PhosphorWayland::SessionLock::isLocked

(

)

const

True between locked() and unlockAndDestroy() (or a compositor-driven finished()).

isSupported()

static bool PhosphorWayland::SessionLock::isSupported ( )

static

True iff the compositor advertises ext_session_lock_manager_v1.

The constructor still succeeds when unsupported, but lock() is a no-op.

lock()

void PhosphorWayland::SessionLock::lock

(

)

Request that the session be locked.

The compositor replies with exactly one of locked() or finished(). A no-op if a lock is already in progress, the session is already locked by this object, or the protocol is unsupported.

locked

void PhosphorWayland::SessionLock::locked ( )

signal

The session is now locked; this client owns the lock and must call unlockAndDestroy() to release it.

lockedChanged

void PhosphorWayland::SessionLock::lockedChanged ( )

signal

isLocked() changed.

unlockAndDestroy()

void PhosphorWayland::SessionLock::unlockAndDestroy

(

)

Release the lock after a successful authentication: sends unlock_and_destroy and flushes.

Valid only after locked() was emitted; a no-op otherwise. Emits lockedChanged() but NOT finished(): finished() signals a compositor-driven end of the lock, whereas this is the client-driven unlock, so a consumer must model unlock success off this call (or lockedChanged()), not off finished().

---

The documentation for this class was generated from the following file:

• phosphor-wayland/include/PhosphorWayland/SessionLock.h