summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorNicolas Frattaroli <nicolas.frattaroli@collabora.com>2026-06-09 14:43:50 +0200
committerDaniel Stone <daniels@collabora.com>2026-06-09 21:03:50 +0100
commit1b61bea2373d157a8b9db0e7304ec72fd80f0759 (patch)
tree95358f15fadbe88432875d5d1ae453f3f12aec6e /include
parent851ae5e3be7288d9958d3d5672bd5d934b2a5aa7 (diff)
drm: Add new general DRM property "color format"
Add a new general DRM property named "color format" which can be used by userspace to request the display driver to output a particular color format. Possible string values for the new enum property are: - "AUTO" (setup by default, driver internally picks the color format) - "RGB" - "YUV 4:4:4" - "YUV 4:2:2" - "YUV 4:2:0" Drivers should advertise from this list the formats they support in an optimistic best-case scenario. EDID data from the sink can then be used in the kernel's atomic check phase to restrict this set of formats, as well as by userspace to make a correct choice in the first place. Co-developed-by: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Co-developed-by: Andri Yngvason <andri@yngvason.is> Signed-off-by: Andri Yngvason <andri@yngvason.is> Signed-off-by: Marius Vlad <marius.vlad@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniel@fooishbar.org> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20260609-color-format-v17-3-35739b5782cc@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
Diffstat (limited to 'include')
-rw-r--r--include/drm/drm_connector.h84
1 files changed, 84 insertions, 0 deletions
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 529755c2e862..e1f6072ce7c9 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -571,12 +571,80 @@ enum drm_colorspace {
* YCbCr 4:2:2 output format (ie. with horizontal subsampling)
* @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
* YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
+ * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
+ * Number of valid output color format values in this enum
*/
enum drm_output_color_format {
DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
+ DRM_OUTPUT_COLOR_FORMAT_COUNT,
+};
+
+/**
+ * enum drm_connector_color_format - Connector Color Format Request
+ *
+ * This enum, unlike &enum drm_output_color_format, is used to specify requests
+ * for a specific color format on a connector through the DRM "color format"
+ * property. The difference is that it has an "AUTO" value to specify that
+ * no specific choice has been made.
+ */
+enum drm_connector_color_format {
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
+ * helpers should pick a suitable color format. All implementations of a
+ * specific display protocol must behave the same way with "AUTO", but
+ * different display protocols do not necessarily have the same "AUTO"
+ * semantics.
+ *
+ * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
+ * bandwidth required for full-scale RGB is not available, or the mode
+ * is YCbCr 4:2:0-only, as long as the mode and output both support
+ * YCbCr 4:2:0.
+ *
+ * For display protocols other than HDMI, the recursive bridge chain
+ * format selection picks the first chain of bridge formats that works,
+ * as has already been the case before the introduction of the "color
+ * format" property. Non-HDMI bridges should therefore either sort their
+ * bus output formats by preference, or agree on a unified auto format
+ * selection logic that's implemented in a common state helper (like
+ * how HDMI does it).
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format. The
+ * quantization range depends on the value of the "Broadcast RGB"
+ * property if it is present on the connector.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_RGB444,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
+ * not subsampled). Quantization range is "Limited" by default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
+ * with horizontal subsampling). Quantization range is "Limited" by
+ * default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
+ * with horizontal and vertical subsampling). Quantization range is
+ * "Limited" by default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_COUNT: Number of valid connector color
+ * format values in this enum
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_COUNT,
};
const char *
@@ -1168,6 +1236,13 @@ struct drm_connector_state {
enum drm_colorspace colorspace;
/**
+ * @color_format: State variable for Connector property to request
+ * color format change on Sink. This is most commonly used to switch
+ * between RGB to YUV and vice-versa.
+ */
+ enum drm_connector_color_format color_format;
+
+ /**
* @writeback_job: Writeback job for writeback connectors
*
* Holds the framebuffer and out-fence for a writeback connector. As
@@ -2182,6 +2257,12 @@ struct drm_connector {
struct drm_property *colorspace_property;
/**
+ * @color_format_property: Connector property to set the suitable
+ * color format supported by the sink.
+ */
+ struct drm_property *color_format_property;
+
+ /**
* @path_blob_ptr:
*
* DRM blob property data for the DP MST path property. This should only
@@ -2664,6 +2745,9 @@ bool drm_connector_has_possible_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
+int drm_connector_attach_color_format_property(struct drm_connector *connector,
+ unsigned long supported_color_formats);
+
/**
* drm_for_each_connector_iter - connector_list iterator macro
* @connector: &struct drm_connector pointer used as cursor