ext_session_lock_v1 Module

ExtSessionLockManagerV1

class pywayland.protocol.ext_session_lock_v1.ExtSessionLockManagerV1

Used to lock the session

This interface is used to request that the session be locked.

destroy() → 'None'

Request – opcode 0 (attached to Resource instance)

Destroy the session lock manager object

This informs the compositor that the session lock manager object will no longer be used. Existing objects created through this interface remain valid.

lock() → 'Proxy[ExtSessionLockV1]'

Request – opcode 1 (attached to Resource instance)

Attempt to lock the session

This request creates a session lock and asks the compositor to lock the session. The compositor will send either the ExtSessionLockV1.locked() or ExtSessionLockV1.finished() event on the created object in response to this request.

Returns:ExtSessionLockV1

ExtSessionLockSurfaceV1

class pywayland.protocol.ext_session_lock_v1.ExtSessionLockSurfaceV1

A surface displayed while the session is locked

The client may use lock surfaces to display a screensaver, render a dialog to enter a password and unlock the session, or however else it sees fit.

On binding this interface the compositor will immediately send the first configure event. After making the ack_configure request in response to this event the client may attach and commit the first buffer. Committing the surface before acking the first configure is a protocol error. Committing the surface with a null buffer at any time is a protocol error.

The compositor is free to handle keyboard/pointer focus for lock surfaces however it chooses. A reasonable way to do this would be to give the first lock surface created keyboard focus and change keyboard focus if the user clicks on other surfaces.

destroy() → 'None'

Request – opcode 0 (attached to Resource instance)

Destroy the lock surface object

This informs the compositor that the lock surface object will no longer be used.

It is recommended for a lock client to destroy lock surfaces if their corresponding WlOutput global is removed.

If a lock surface on an active output is destroyed before the ExtSessionLockV1.unlock_and_destroy() event is sent, the compositor must fall back to rendering a solid color.

ack_configure(serial: 'int') → 'None'

Request – opcode 1 (attached to Resource instance)

Ack a configure event

When a configure event is received, if a client commits the surface in response to the configure event, then the client must make an ack_configure request sometime before the commit request, passing along the serial of the configure event.

If the client receives multiple configure events before it can respond to one, it only has to ack the last configure event.

A client is not required to commit immediately after sending an ack_configure request - it may even ack_configure several times before its next surface commit.

A client may send multiple ack_configure requests before committing, but only the last request sent before a commit indicates which configure event the client really is responding to.

Sending an ack_configure request consumes the configure event referenced by the given serial, as well as all older configure events sent on this object.

It is a protocol error to issue multiple ack_configure requests referencing the same configure event or to issue an ack_configure request referencing a configure event older than the last configure event acked for a given lock surface.

Parameters:serial (ArgumentType.Uint) – serial from the configure event

configure(serial: 'int', width: 'int', height: 'int') → 'None'

Event – opcode 0 (attached to Proxy instance)

The client should resize its surface

This event is sent once on binding the interface and may be sent again at the compositor’s discretion, for example if output geometry changes.

The width and height are in surface-local coordinates and are exact requirements. Failing to match these surface dimensions in the next commit after acking a configure is a protocol error.

Parameters:

• serial (ArgumentType.Uint) – serial for use in ack_configure
• width (ArgumentType.Uint) –
• height (ArgumentType.Uint) –

ExtSessionLockV1

class pywayland.protocol.ext_session_lock_v1.ExtSessionLockV1

Manage lock state and create lock surfaces

On creation of this object either the locked or finished event will immediately be sent.

The locked event indicates that the session is locked. This means that the compositor should stop rendering and providing input to normal clients. Instead the compositor should 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.

If the client dies while the session is locked, the compositor should 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 ExtSessionLockV1 object and take responsibility for unlocking the session, they may even start a new lock client instance automatically.

destroy() → 'None'

Request – opcode 0 (attached to Resource instance)

Destroy the session lock

This informs the compositor that the lock object will no longer be used. Existing objects created through this interface remain valid.

After this request is made, lock surfaces created through this object should be destroyed by the client as they will no longer be used by the compositor.

It is a protocol error to make this request if the locked event was sent, the unlock_and_destroy request must be used instead.

get_lock_surface(surface: 'WlSurface', output: 'WlOutput') → 'Proxy[ExtSessionLockSurfaceV1]'

Request – opcode 1 (attached to Resource instance)

Create a lock surface for a given output

The client is expected to create lock surfaces for all outputs currently present and any new outputs as they are advertised. These won’t be displayed by the compositor unless the lock is successful and the locked event is sent.

Providing a WlSurface which already has a role or already has a buffer attached or committed is a protocol error, as is attaching/committing a buffer before the first ExtSessionLockSurfaceV1.configure() event.

Attempting to create more than one lock surface for a given output is a duplicate_output protocol error.

Parameters:

• surface (WlSurface) –
• output (WlOutput) –

Returns:

ExtSessionLockSurfaceV1

unlock_and_destroy() → 'None'

Request – opcode 2 (attached to Resource instance)

Unlock the session, destroying the object

This request indicates that the session should be unlocked, for example because the user has entered their password and it has been verified by the client.

This request also informs the compositor that the lock object will no longer be used and may be safely destroyed. Existing objects created through this interface remain valid.

After this request is made, lock surfaces created through this object should be destroyed by the client as they will no longer be used by the compositor.

It is a protocol error to make this request if the locked event has not been sent. In that case, the lock object may only be destroyed using the destroy request.

locked() → 'None'

Event – opcode 0 (attached to Proxy instance)

Session successfully locked

This client is now responsible for displaying graphics while the session is locked and deciding when to unlock the session.

Either this event or the finished event will be sent immediately on creation of this object.

If this event is sent, making the destroy request is a protocol error, the lock object may only be destroyed using the unlock_and_destroy request.

finished() → 'None'

Event – opcode 1 (attached to Proxy instance)

The session lock object should be destroyed

The compositor has decided that the session lock should be destroyed. Exactly when this event is sent is compositor policy, but it will never be sent more than once for a given session lock object.

This might be sent because there is already another ExtSessionLockV1 object held by a client, or the compositor has decided to deny the request to lock the session for some other reason. This might also be sent because the compositor implements some alternative, secure way to authenticate and unlock the session.

Either this event or the locked event will be sent exactly once on creation of this object. If the locked event is sent on creation of this object, the finished event may still be sent at some later time in this object’s lifetime, this is compositor policy.

Upon receiving this event, the client should make either the destroy request or the unlock_and_destroy request, depending on whether or not the locked event was received on this object.