Enum wayland_client::protocol::wl_output::Event
source · #[non_exhaustive]pub enum Event {
Geometry {
x: i32,
y: i32,
physical_width: i32,
physical_height: i32,
subpixel: WEnum<Subpixel>,
make: String,
model: String,
transform: WEnum<Transform>,
},
Mode {
flags: WEnum<Mode>,
width: i32,
height: i32,
refresh: i32,
},
Done,
Scale {
factor: i32,
},
Name {
name: String,
},
Description {
description: String,
},
}
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
Geometry
properties of the output
The geometry event describes geometric properties of the output. The event is sent when binding to the output object and whenever any of the properties change.
The physical size can be set to zero if it doesn’t make sense for this output (e.g. for projectors or virtual outputs).
The geometry event will be followed by a done event (starting from version 2).
Clients should use wl_surface.preferred_buffer_transform instead of the transform advertised by this event to find the preferred buffer transform to use for a surface.
Note: wl_output only advertises partial information about the output position and identification. Some compositors, for instance those not implementing a desktop-style output layout or those exposing virtual outputs, might fake this information. Instead of using x and y, clients should use xdg_output.logical_position. Instead of using make and model, clients should use name and description.
Fields
Mode
advertise available modes for the output
The mode event describes an available mode for the output.
The event is sent when binding to the output object and there will always be one mode, the current mode. The event is sent again if an output changes mode, for the mode that is now current. In other words, the current mode is always the last mode that was received with the current flag set.
Non-current modes are deprecated. A compositor can decide to only advertise the current mode and never send other modes. Clients should not rely on non-current modes.
The size of a mode 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, as described in wl_output.scale, or transformed, as described in wl_output.transform. Clients willing to retrieve the output size in the global compositor space should use xdg_output.logical_size instead.
The vertical refresh rate can be set to zero if it doesn’t make sense for this output (e.g. for virtual outputs).
The mode event will be followed by a done event (starting from version 2).
Clients should not use the refresh rate to schedule frames. Instead, they should use the wl_surface.frame event or the presentation-time protocol.
Note: this information is not always meaningful for all outputs. Some compositors, such as those exposing virtual outputs, might fake the refresh rate or the size.
Fields
Done
sent all information about output
This event is sent after all other properties have been sent after binding to the output object and after any other property changes done after that. This allows changes to the output properties to be seen as atomic, even if they happen via multiple events.
Only available since version 2 of the interface
Scale
output scaling properties
This event contains scaling geometry information that is not in the geometry event. It may be sent after binding the output object or if the output scale changes later. The compositor will emit a non-zero, positive value for scale. If it is not sent, the client should assume a scale of 1.
A scale larger than 1 means that the compositor will automatically scale surface buffers by this amount when rendering. This is used for very high resolution displays where applications rendering at the native resolution would be too small to be legible.
Clients should use wl_surface.preferred_buffer_scale instead of this event to find the preferred buffer scale to use for a surface.
The scale event will be followed by a done event.
Only available since version 2 of the interface
Name
name of this output
Many compositors will assign user-friendly names to their outputs, show them to the user, allow the user to refer to an output, etc. The client may wish to know this name as well to offer the user similar behaviors.
The name is a UTF-8 string with no convention defined for its contents. Each name is unique among all wl_output globals. The name is only guaranteed to be unique for the compositor instance.
The same output name is used for all clients for a given wl_output global. Thus, the name can be shared across processes to refer to a specific wl_output global.
The name is not guaranteed to be persistent across sessions, thus cannot be used to reliably identify an output in e.g. configuration files.
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.
The name event is sent after binding the output object. This event is only sent once per output object, and the name does not change over the lifetime of the wl_output global.
Compositors may re-use the same output name if the wl_output global is destroyed and re-created later. Compositors should avoid re-using the same name if possible.
The name event will be followed by a done event.
Only available since version 4 of the interface
Description
human-readable description of this output
Many compositors can produce human-readable descriptions of their outputs. The client may wish to know this description as well, e.g. for output selection purposes.
The description is a UTF-8 string with no convention defined for its contents. The description is not guaranteed to be unique among all wl_output globals. Examples might include ‘Foocorp 11“ Display’ or ‘Virtual X11 output via :1’.
The description event is sent after binding the output object and whenever the description changes. The description is optional, and may not be sent at all.
The description event will be followed by a done event.
Only available since version 4 of the interface
Implementations§
Trait Implementations§
Auto Trait Implementations§
impl Freeze for Event
impl RefUnwindSafe for Event
impl Send for Event
impl Sync for Event
impl Unpin for Event
impl UnwindSafe for Event
Blanket Implementations§
source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
source§impl<T> Downcast for Twhere
T: Any,
impl<T> Downcast for Twhere
T: Any,
source§fn into_any(self: Box<T>) -> Box<dyn Any>
fn into_any(self: Box<T>) -> Box<dyn Any>
Box<dyn Trait>
(where Trait: Downcast
) to Box<dyn Any>
. Box<dyn Any>
can
then be further downcast
into Box<ConcreteType>
where ConcreteType
implements Trait
.source§fn into_any_rc(self: Rc<T>) -> Rc<dyn Any>
fn into_any_rc(self: Rc<T>) -> Rc<dyn Any>
Rc<Trait>
(where Trait: Downcast
) to Rc<Any>
. Rc<Any>
can then be
further downcast
into Rc<ConcreteType>
where ConcreteType
implements Trait
.source§fn as_any(&self) -> &(dyn Any + 'static)
fn as_any(&self) -> &(dyn Any + 'static)
&Trait
(where Trait: Downcast
) to &Any
. This is needed since Rust cannot
generate &Any
’s vtable from &Trait
’s.source§fn as_any_mut(&mut self) -> &mut (dyn Any + 'static)
fn as_any_mut(&mut self) -> &mut (dyn Any + 'static)
&mut Trait
(where Trait: Downcast
) to &Any
. This is needed since Rust cannot
generate &mut Any
’s vtable from &mut Trait
’s.