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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
