[RFC 03/11] drm: add DRM_MODE_PROP_DYNAMIC property flag

[Rob Clark]

From: Rob Clark 

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 dff792f..e03ece6 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 / 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)

 struct drm_mode_property_enum {
__u64 value;
-- 
1.7.9.5

[RFC 03/11] drm: add DRM_MODE_PROP_DYNAMIC property flag

[Rob Clark]

From: Rob Clark r...@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 dff792f..e03ece6 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 (14)
 #define DRM_MODE_PROP_BITMASK  (15) /* bitmask of enumerated types */
 #define DRM_MODE_PROP_OBJECT   (16) /* 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  (124)
 
 struct drm_mode_property_enum {
__u64 value;
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 03/11] drm: add DRM_MODE_PROP_DYNAMIC property flag

[Rob Clark]

From: Rob Clark r...@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..15689d4 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 (14)
 #define DRM_MODE_PROP_BITMASK  (15) /* bitmask of enumerated types */
 #define DRM_MODE_PROP_OBJECT   (16) /* 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  (124)
 
 struct drm_mode_property_enum {
__u64 value;
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 03/11] drm: add DRM_MODE_PROP_DYNAMIC property flag

[Rob Clark]

From: Rob Clark 

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..15689d4 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 / 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)

 struct drm_mode_property_enum {
__u64 value;
-- 
1.7.9.5