From: Rob Clark rob@ti.com
This indicates to userspace that the property is something that can be set dynamically without requiring a "test" step to check if the hw is capable. This allows a userspace compositor, such as weston, to avoid an extra ioctl to check whether it needs to fall-back to GPU to composite some surface prior to submission of GPU render commands. --- include/drm/drm_mode.h | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h index cee4c53..8cec2cf 100644 --- a/include/drm/drm_mode.h +++ b/include/drm/drm_mode.h @@ -232,6 +232,15 @@ struct drm_mode_get_connector { #define DRM_MODE_PROP_BLOB (1<<4) #define DRM_MODE_PROP_BITMASK (1<<5) /* bitmask of enumerated types */ #define DRM_MODE_PROP_OBJECT (1<<6) /* drm mode object */ +/* Properties that are not dynamic cannot safely be changed without a + * atomic-modeset / nuclear-pageflip test step. But if userspace is + * only changing dynamic properties, it is garanteed that the change + * will not exceed hw limits, so no test step is required. + * + * Note that fb_id properties are a bit ambiguous.. they of course can + * be changed dynamically, assuming the pixel format does not change. + */ +#define DRM_MODE_PROP_DYNAMIC (1<<24)
struct drm_mode_property_enum { __u64 value;