wlr output management

Create a new output configuration object. This allows to update head properties.

Indicates the client no longer wishes to receive events for output configuration changes. However the compositor may emit further events, until the finished event is emitted.

The client must not send any more requests after this one.

This event introduces a new head. This happens whenever a new head appears (e.g. a monitor is plugged in) or after the output manager is bound.

This event is sent after all information has been sent after binding to the output manager object and after any subsequent changes. This applies to child head and mode objects as well. In other words, this event is sent whenever a head or mode is created or destroyed and whenever one of their properties has been changed. Not all state is re-sent each time the current configuration changes: only the actual changes are sent.

This allows changes to the output configuration to be seen as atomic, even if they happen via multiple events.

A serial is sent to be used in a future create_configuration request.

This event indicates that the compositor is done sending manager events. The compositor will destroy the object immediately after sending this event, so it will become invalid and the client should release any resources associated with it.

This request indicates that the client will no longer use this head object.

This event describes the head name.

The naming convention is compositor defined, but limited to alphanumeric characters and dashes (-). Each name is unique among all wlr_output_head objects, but if a wlr_output_head object is destroyed the same name may be reused later. The names will also remain consistent across sessions with the same hardware and software configuration.

Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do not assume that the name is a reflection of an underlying DRM connector, X11 connection, etc.

If the compositor implements the xdg-output protocol and this head is enabled, the xdg_output.name event must report the same name.

The name event is sent after a wlr_output_head object is created. This event is only sent once per object, and the name does not change over the lifetime of the wlr_output_head object.

This event describes a human-readable description of the head.

The description is a UTF-8 string with no convention defined for its contents. Examples might include 'Foocorp 11" Display' or 'Virtual X11 output via :1'. However, do not assume that the name is a reflection of the make, model, serial of the underlying DRM connector or the display name of the underlying X11 connection, etc.

If the compositor implements xdg-output and this head is enabled, the xdg_output.description must report the same description.

The description event is sent after a wlr_output_head object is created. This event is only sent once per object, and the description does not change over the lifetime of the wlr_output_head object.

This event describes the physical size of the head. This event is only sent if the head has a physical size (e.g. is not a projector or a virtual device).

This event introduces a mode for this head. It is sent once per supported mode.

This event describes whether the head is enabled. A disabled head is not mapped to a region of the global compositor space.

When a head is disabled, some properties (current_mode, position, transform and scale) are irrelevant.

This event describes the mode currently in use for this head. It is only sent if the output is enabled.

This events describes the position of the head in the global compositor space. It is only sent if the output is enabled.

This event describes the transformation currently applied to the head. It is only sent if the output is enabled.

This events describes the scale of the head in the global compositor space. It is only sent if the output is enabled.

This event indicates that the head is no longer available. The head object becomes inert. Clients should send a destroy request and release any resources associated with it.

This event describes the manufacturer of the head.

This must report the same make as the wl_output interface does in its geometry event.

Together with the model and serial_number events the purpose is to allow clients to recognize heads from previous sessions and for example load head-specific configurations back.

It is not guaranteed this event will be ever sent. A reason for that can be that the compositor does not have information about the make of the head or the definition of a make is not sensible in the current setup, for example in a virtual session. Clients can still try to identify the head by available information from other events but should be aware that there is an increased risk of false positives.

It is not recommended to display the make string in UI to users. For that the string provided by the description event should be preferred.

This event describes the model of the head.

This must report the same model as the wl_output interface does in its geometry event.

Together with the make and serial_number events the purpose is to allow clients to recognize heads from previous sessions and for example load head-specific configurations back.

It is not guaranteed this event will be ever sent. A reason for that can be that the compositor does not have information about the model of the head or the definition of a model is not sensible in the current setup, for example in a virtual session. Clients can still try to identify the head by available information from other events but should be aware that there is an increased risk of false positives.

It is not recommended to display the model string in UI to users. For that the string provided by the description event should be preferred.

This event describes the serial number of the head.

Together with the make and model events the purpose is to allow clients to recognize heads from previous sessions and for example load head- specific configurations back.

It is not guaranteed this event will be ever sent. A reason for that can be that the compositor does not have information about the serial number of the head or the definition of a serial number is not sensible in the current setup. Clients can still try to identify the head by available information from other events but should be aware that there is an increased risk of false positives.

It is not recommended to display the serial_number string in UI to users. For that the string provided by the description event should be preferred.

This event describes whether adaptive sync is currently enabled for the head or not. Adaptive sync is also known as Variable Refresh Rate or VRR.

This request indicates that the client will no longer use this mode object.

This event describes the mode size. The size is given in physical hardware units of the output device. This is not necessarily the same as the output size in the global compositor space. For instance, the output may be scaled or transformed.

This event describes the mode's fixed vertical refresh rate. It is only sent if the mode has a fixed refresh rate.

This event advertises this mode as preferred.

This event indicates that the mode is no longer available. The mode object becomes inert. Clients should send a destroy request and release any resources associated with it.

Enable a head. This request creates a head configuration object that can be used to change the head's properties.

Disable a head.

Apply the new output configuration.

In case the configuration is successfully applied, there is no guarantee that the new output state matches completely the requested configuration. For instance, a compositor might round the scale if it doesn't support fractional scaling.

After this request has been sent, the compositor must respond with an succeeded, failed or cancelled event. Sending a request that isn't the destructor is a protocol error.

Test the new output configuration. The configuration won't be applied, but will only be validated.

Even if the compositor succeeds to test a configuration, applying it may fail.

After this request has been sent, the compositor must respond with an succeeded, failed or cancelled event. Sending a request that isn't the destructor is a protocol error.

Using this request a client can tell the compositor that it is not going to use the configuration object anymore. Any changes to the outputs that have not been applied will be discarded.

This request also destroys wlr_output_configuration_head objects created via this object.

Sent after the compositor has successfully applied the changes or tested them.

Upon receiving this event, the client should destroy this object.

If the current configuration has changed, events to describe the changes will be sent followed by a wlr_output_manager.done event.

Sent if the compositor rejects the changes or failed to apply them. The compositor should revert any changes made by the apply request that triggered this event.

Upon receiving this event, the client should destroy this object.

Sent if the compositor cancels the configuration because the state of an output changed and the client has outdated information (e.g. after an output has been hotplugged).

The client can create a new configuration with a newer serial and try again.

Upon receiving this event, the client should destroy this object.

This request sets the head's mode.

This request assigns a custom mode to the head. The size is given in physical hardware units of the output device. If set to zero, the refresh rate is unspecified.

It is a protocol error to set both a mode and a custom mode.

This request sets the head's position in the global compositor space.

This request sets the head's transform.

This request sets the head's scale.

This request enables/disables adaptive sync. Adaptive sync is also known as Variable Refresh Rate or VRR.