struct drm_crtc_state — mutable CRTC state
struct drm_crtc_state { struct drm_crtc * crtc; bool enable; bool active; bool planes_changed:1; bool mode_changed:1; bool active_changed:1; bool connectors_changed:1; bool color_mgmt_changed:1; u32 plane_mask; u32 connector_mask; u32 encoder_mask; u32 last_vblank_count; struct drm_display_mode adjusted_mode; struct drm_display_mode mode; struct drm_property_blob * degamma_lut; struct drm_property_blob * ctm; struct drm_property_blob * gamma_lut; struct drm_pending_vblank_event * event; struct drm_atomic_state * state; };
backpointer to the CRTC
whether the CRTC should be enabled, gates all other state
whether the CRTC is actively displaying (used for DPMS)
planes on this crtc are updated
crtc_state->mode or crtc_state->enable has been changed
crtc_state->active has been toggled.
connectors to this crtc have been updated
color management properties have changed (degamma or gamma LUT or CSC matrix)
bitmask of (1 << drm_plane_index(plane)) of attached planes
bitmask of (1 << drm_connector_index(connector)) of attached connectors
bitmask of (1 << drm_encoder_index(encoder)) of attached encoders
for helpers and drivers to capture the vblank of the update to ensure framebuffer cleanup isn't done too early
for use by helpers and drivers to compute adjusted mode timings
current mode timings
Lookup table for converting framebuffer pixel data before apply the conversion matrix
Transformation matrix
Lookup table for converting pixel data after the conversion matrix
optional pointer to a DRM event to signal upon completion of the state update
backpointer to global drm_atomic_state
Note that the distinction between enable
and active
is rather subtile:
Flipping active
while enable
is set without changing anything else may
never return in a failure from the ->atomic_check callback. Userspace assumes
that a DPMS On will always succeed. In other words: enable
controls resource
assignment, active
controls the actual hardware state.