[RFCv1 03/12] drm: add DRM_MODE_PROP_DYNAMIC property flag

[Ville Syrjälä]

On Sat, Oct 05, 2013 at 08:45:41PM -0400, Rob Clark wrote:
> 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/uapi/drm/drm_mode.h | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 35921ba..15db837 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/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 / atomic-pageflip test step.  But if userspace is
> + * only changing dynamic properties, it is guaranteed 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)

I'm still not convinced that this is useful. We can't even flag the FB
ID with this flag since the FB encompasses stride/bpp/etc. parameters
that for sure can't just be changed w/o first checking the new
configuration.

-- 
Ville Syrjälä
Intel OTC