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 options are:
- auto (setup by default, driver internally picks the color format)
- rgb
- ycbcr444
- ycbcr422
- ycbcr420
Drivers should advertise from this list which formats they support.
Together with this list and EDID data from the sink we should be able
to relay a list of usable color formats to users to pick from.
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>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 5 ++
drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++
drivers/gpu/drm/drm_connector.c | 108 ++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 104 ++++++++++++++++++++++++++++++++++
4 files changed, 228 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 26953ed6b53e..b7753454b777 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->max_requested_bpc !=
new_connector_state->max_requested_bpc)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->color_format !=
+ new_connector_state->color_format)
+ new_crtc_state->connectors_changed = true;
+
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 5bd5bf6661df..dee510c85e59 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
state->privacy_screen_sw_state = val;
} else if (property == connector->broadcast_rgb_property) {
state->hdmi.broadcast_rgb = val;
+ } else if (property == connector->color_format_property) {
+ if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
+ drm_dbg_atomic(connector->dev,
+ "[CONNECTOR:%d:%s] unknown color format %llu\n",
+ connector->base.id, connector->name, val);
+ return -EINVAL;
+ }
+
+ state->color_format = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
*val = state->privacy_screen_sw_state;
} else if (property == connector->broadcast_rgb_property) {
*val = state->hdmi.broadcast_rgb;
+ } else if (property == connector->color_format_property) {
+ *val = state->color_format;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 47dc53c4a738..e848374dee0b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
+static const u32 hdmi_colorformats =
+ BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
+
+static const u32 dp_colorformats =
+ BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
+
/*
* As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
* Format Table 2-120
@@ -2940,6 +2952,102 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
}
EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
+/**
+ * drm_connector_attach_color_format_property - create and attach color format property
+ * @connector: connector to create the color format property on
+ * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
+ * values the connector supports
+ *
+ * Called by a driver to create a color format property. The property is
+ * attached to the connector automatically on success.
+ *
+ * @supported_color_formats should only include color formats the connector
+ * type can actually support.
+ *
+ * Returns:
+ * 0 on success, negative errno on error
+ */
+int drm_connector_attach_color_format_property(struct drm_connector *connector,
+ unsigned long supported_color_formats)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
+ unsigned int i = 0;
+ unsigned long fmt;
+
+ if (connector->color_format_property)
+ return 0;
+
+ if (!supported_color_formats) {
+ drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
+ if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
+ drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_HDMIA:
+ case DRM_MODE_CONNECTOR_HDMIB:
+ if (supported_color_formats & ~hdmi_colorformats) {
+ drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+ break;
+ case DRM_MODE_CONNECTOR_DisplayPort:
+ case DRM_MODE_CONNECTOR_eDP:
+ if (supported_color_formats & ~dp_colorformats) {
+ drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+ break;
+ }
+
+ enum_list[0].name = "AUTO";
+ enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
+
+ for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
+ switch (fmt) {
+ case DRM_OUTPUT_COLOR_FORMAT_RGB444:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
+ break;
+ default:
+ drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
+ fmt, connector->base.id, connector->name);
+ continue;
+ }
+ enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
+ }
+
+ connector->color_format_property =
+ drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
+ enum_list, i + 1);
+
+ if (!connector->color_format_property)
+ return -ENOMEM;
+
+ drm_object_attach_property(&connector->base, connector->color_format_property,
+ DRM_CONNECTOR_COLOR_FORMAT_AUTO);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_color_format_property);
+
/**
* drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
* @old_state: old connector state to compare
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index af8b92d2d5b7..bd549f912b76 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -571,14 +571,102 @@ 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
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_RGB444,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
+ * not subsampled)
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
+ * with horizontal subsampling)
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
+ * with horizontal and vertical subsampling)
+ */
+ 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,
+};
+
+/**
+ * drm_connector_color_format_valid - Validate drm_connector_color_format value
+ * @fmt: value to check against all values of &enum drm_connector_color_format
+ *
+ * Checks whether the passed in value of @fmt is one of the allowable values in
+ * &enum drm_connector_color_format.
+ *
+ * Returns: %true if it's a valid value for the enum, %false otherwise.
+ */
+static inline bool __pure
+drm_connector_color_format_valid(enum drm_connector_color_format fmt)
+{
+ switch (fmt) {
+ case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
+ case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
+ return true;
+ default:
+ return false;
+ }
+}
+
const char *
drm_hdmi_connector_get_output_format_name(enum drm_output_color_format fmt);
@@ -1129,6 +1217,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
*
@@ -2127,6 +2222,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:
*
@@ -2610,6 +2711,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
--
2.53.0On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> 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 options are:
> - auto (setup by default, driver internally picks the color format)
> - rgb
> - ycbcr444
> - ycbcr422
> - ycbcr420
>
> Drivers should advertise from this list which formats they support.
> Together with this list and EDID data from the sink we should be able
> to relay a list of usable color formats to users to pick from.
>
> 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>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 5 ++
> drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++
> drivers/gpu/drm/drm_connector.c | 108 ++++++++++++++++++++++++++++++++++++
> include/drm/drm_connector.h | 104 ++++++++++++++++++++++++++++++++++
> 4 files changed, 228 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 26953ed6b53e..b7753454b777 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->max_requested_bpc !=
> new_connector_state->max_requested_bpc)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->color_format !=
> + new_connector_state->color_format)
> + new_crtc_state->connectors_changed = true;
> +
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index 5bd5bf6661df..dee510c85e59 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> state->privacy_screen_sw_state = val;
> } else if (property == connector->broadcast_rgb_property) {
> state->hdmi.broadcast_rgb = val;
> + } else if (property == connector->color_format_property) {
> + if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
> + drm_dbg_atomic(connector->dev,
> + "[CONNECTOR:%d:%s] unknown color format %llu\n",
> + connector->base.id, connector->name, val);
> + return -EINVAL;
> + }
> +
> + state->color_format = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> *val = state->privacy_screen_sw_state;
> } else if (property == connector->broadcast_rgb_property) {
> *val = state->hdmi.broadcast_rgb;
> + } else if (property == connector->color_format_property) {
> + *val = state->color_format;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 47dc53c4a738..e848374dee0b 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
> BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
>
> +static const u32 hdmi_colorformats =
> + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> +
> +static const u32 dp_colorformats =
> + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> +
> /*
> * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
> * Format Table 2-120
> @@ -2940,6 +2952,102 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
> }
> EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
>
> +/**
> + * drm_connector_attach_color_format_property - create and attach color format property
> + * @connector: connector to create the color format property on
> + * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
> + * values the connector supports
> + *
> + * Called by a driver to create a color format property. The property is
> + * attached to the connector automatically on success.
> + *
> + * @supported_color_formats should only include color formats the connector
> + * type can actually support.
> + *
> + * Returns:
> + * 0 on success, negative errno on error
> + */
> +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> + unsigned long supported_color_formats)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
> + unsigned int i = 0;
> + unsigned long fmt;
> +
> + if (connector->color_format_property)
> + return 0;
> +
> + if (!supported_color_formats) {
> + drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
> + connector->base.id, connector->name);
> + return -EINVAL;
> + }
> +
> + if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
> + drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
> + connector->base.id, connector->name);
> + return -EINVAL;
> + }
> +
> + switch (connector->connector_type) {
> + case DRM_MODE_CONNECTOR_HDMIA:
> + case DRM_MODE_CONNECTOR_HDMIB:
> + if (supported_color_formats & ~hdmi_colorformats) {
> + drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
> + connector->base.id, connector->name);
> + return -EINVAL;
> + }
> + break;
> + case DRM_MODE_CONNECTOR_DisplayPort:
> + case DRM_MODE_CONNECTOR_eDP:
> + if (supported_color_formats & ~dp_colorformats) {
> + drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
> + connector->base.id, connector->name);
> + return -EINVAL;
> + }
> + break;
> + }
> +
> + enum_list[0].name = "AUTO";
> + enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
> +
> + for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
> + switch (fmt) {
> + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> + break;
> + default:
> + drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
> + fmt, connector->base.id, connector->name);
> + continue;
> + }
> + enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
> + }
> +
> + connector->color_format_property =
> + drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
> + enum_list, i + 1);
> +
> + if (!connector->color_format_property)
> + return -ENOMEM;
> +
> + drm_object_attach_property(&connector->base, connector->color_format_property,
> + DRM_CONNECTOR_COLOR_FORMAT_AUTO);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_color_format_property);
> +
> /**
> * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
> * @old_state: old connector state to compare
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index af8b92d2d5b7..bd549f912b76 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -571,14 +571,102 @@ 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.
Is there a reason you propose dropping back to YCbCr 4:2:0 without
trying YCbCr 4:2:2 first? Minimising the subsampling is surely
beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
Dave
> + *
> + * 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
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> + * not subsampled)
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> + * with horizontal subsampling)
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> + * with horizontal and vertical subsampling)
> + */
> + 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,
> +};
> +
> +/**
> + * drm_connector_color_format_valid - Validate drm_connector_color_format value
> + * @fmt: value to check against all values of &enum drm_connector_color_format
> + *
> + * Checks whether the passed in value of @fmt is one of the allowable values in
> + * &enum drm_connector_color_format.
> + *
> + * Returns: %true if it's a valid value for the enum, %false otherwise.
> + */
> +static inline bool __pure
> +drm_connector_color_format_valid(enum drm_connector_color_format fmt)
> +{
> + switch (fmt) {
> + case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
> + case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> const char *
> drm_hdmi_connector_get_output_format_name(enum drm_output_color_format fmt);
>
> @@ -1129,6 +1217,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
> *
> @@ -2127,6 +2222,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:
> *
> @@ -2610,6 +2711,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
>
> --
> 2.53.0
>
On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com> wrote:
> >
> > 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 options are:
> > - auto (setup by default, driver internally picks the color format)
> > - rgb
> > - ycbcr444
> > - ycbcr422
> > - ycbcr420
> >
> > Drivers should advertise from this list which formats they support.
> > Together with this list and EDID data from the sink we should be able
> > to relay a list of usable color formats to users to pick from.
> >
> > 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>
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 5 ++
> > drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++
> > drivers/gpu/drm/drm_connector.c | 108 ++++++++++++++++++++++++++++++++++++
> > include/drm/drm_connector.h | 104 ++++++++++++++++++++++++++++++++++
> > 4 files changed, 228 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > index 26953ed6b53e..b7753454b777 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > if (old_connector_state->max_requested_bpc !=
> > new_connector_state->max_requested_bpc)
> > new_crtc_state->connectors_changed = true;
> > +
> > + if (old_connector_state->color_format !=
> > + new_connector_state->color_format)
> > + new_crtc_state->connectors_changed = true;
> > +
> > }
> >
> > if (funcs->atomic_check)
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 5bd5bf6661df..dee510c85e59 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> > state->privacy_screen_sw_state = val;
> > } else if (property == connector->broadcast_rgb_property) {
> > state->hdmi.broadcast_rgb = val;
> > + } else if (property == connector->color_format_property) {
> > + if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
> > + drm_dbg_atomic(connector->dev,
> > + "[CONNECTOR:%d:%s] unknown color format %llu\n",
> > + connector->base.id, connector->name, val);
> > + return -EINVAL;
> > + }
> > +
> > + state->color_format = val;
> > } else if (connector->funcs->atomic_set_property) {
> > return connector->funcs->atomic_set_property(connector,
> > state, property, val);
> > @@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> > *val = state->privacy_screen_sw_state;
> > } else if (property == connector->broadcast_rgb_property) {
> > *val = state->hdmi.broadcast_rgb;
> > + } else if (property == connector->color_format_property) {
> > + *val = state->color_format;
> > } else if (connector->funcs->atomic_get_property) {
> > return connector->funcs->atomic_get_property(connector,
> > state, property, val);
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index 47dc53c4a738..e848374dee0b 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
> > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
> >
> > +static const u32 hdmi_colorformats =
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > +
> > +static const u32 dp_colorformats =
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > +
> > /*
> > * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
> > * Format Table 2-120
> > @@ -2940,6 +2952,102 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
> > }
> > EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
> >
> > +/**
> > + * drm_connector_attach_color_format_property - create and attach color format property
> > + * @connector: connector to create the color format property on
> > + * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
> > + * values the connector supports
> > + *
> > + * Called by a driver to create a color format property. The property is
> > + * attached to the connector automatically on success.
> > + *
> > + * @supported_color_formats should only include color formats the connector
> > + * type can actually support.
> > + *
> > + * Returns:
> > + * 0 on success, negative errno on error
> > + */
> > +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> > + unsigned long supported_color_formats)
> > +{
> > + struct drm_device *dev = connector->dev;
> > + struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
> > + unsigned int i = 0;
> > + unsigned long fmt;
> > +
> > + if (connector->color_format_property)
> > + return 0;
> > +
> > + if (!supported_color_formats) {
> > + drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > +
> > + if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
> > + drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > +
> > + switch (connector->connector_type) {
> > + case DRM_MODE_CONNECTOR_HDMIA:
> > + case DRM_MODE_CONNECTOR_HDMIB:
> > + if (supported_color_formats & ~hdmi_colorformats) {
> > + drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > + break;
> > + case DRM_MODE_CONNECTOR_DisplayPort:
> > + case DRM_MODE_CONNECTOR_eDP:
> > + if (supported_color_formats & ~dp_colorformats) {
> > + drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > + break;
> > + }
> > +
> > + enum_list[0].name = "AUTO";
> > + enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
> > +
> > + for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
> > + switch (fmt) {
> > + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> > + break;
> > + default:
> > + drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
> > + fmt, connector->base.id, connector->name);
> > + continue;
> > + }
> > + enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
> > + }
> > +
> > + connector->color_format_property =
> > + drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
> > + enum_list, i + 1);
> > +
> > + if (!connector->color_format_property)
> > + return -ENOMEM;
> > +
> > + drm_object_attach_property(&connector->base, connector->color_format_property,
> > + DRM_CONNECTOR_COLOR_FORMAT_AUTO);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_connector_attach_color_format_property);
> > +
> > /**
> > * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
> > * @old_state: old connector state to compare
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index af8b92d2d5b7..bd549f912b76 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -571,14 +571,102 @@ 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.
>
> Is there a reason you propose dropping back to YCbCr 4:2:0 without
> trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
On HDMI 4:2:2 is always 12bpc, so it doesn't save any bandwidth
compared to 8bpc 4:4:4.
--
Ville Syrjälä
Intel
On Wed, 25 Mar 2026 at 13:43, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli
> > <nicolas.frattaroli@collabora.com> wrote:
> > >
> > > 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 options are:
> > > - auto (setup by default, driver internally picks the color format)
> > > - rgb
> > > - ycbcr444
> > > - ycbcr422
> > > - ycbcr420
> > >
> > > Drivers should advertise from this list which formats they support.
> > > Together with this list and EDID data from the sink we should be able
> > > to relay a list of usable color formats to users to pick from.
> > >
> > > 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>
> > > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 5 ++
> > > drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++
> > > drivers/gpu/drm/drm_connector.c | 108 ++++++++++++++++++++++++++++++++++++
> > > include/drm/drm_connector.h | 104 ++++++++++++++++++++++++++++++++++
> > > 4 files changed, 228 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 26953ed6b53e..b7753454b777 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > > if (old_connector_state->max_requested_bpc !=
> > > new_connector_state->max_requested_bpc)
> > > new_crtc_state->connectors_changed = true;
> > > +
> > > + if (old_connector_state->color_format !=
> > > + new_connector_state->color_format)
> > > + new_crtc_state->connectors_changed = true;
> > > +
> > > }
> > >
> > > if (funcs->atomic_check)
> > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > > index 5bd5bf6661df..dee510c85e59 100644
> > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > @@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> > > state->privacy_screen_sw_state = val;
> > > } else if (property == connector->broadcast_rgb_property) {
> > > state->hdmi.broadcast_rgb = val;
> > > + } else if (property == connector->color_format_property) {
> > > + if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
> > > + drm_dbg_atomic(connector->dev,
> > > + "[CONNECTOR:%d:%s] unknown color format %llu\n",
> > > + connector->base.id, connector->name, val);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + state->color_format = val;
> > > } else if (connector->funcs->atomic_set_property) {
> > > return connector->funcs->atomic_set_property(connector,
> > > state, property, val);
> > > @@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> > > *val = state->privacy_screen_sw_state;
> > > } else if (property == connector->broadcast_rgb_property) {
> > > *val = state->hdmi.broadcast_rgb;
> > > + } else if (property == connector->color_format_property) {
> > > + *val = state->color_format;
> > > } else if (connector->funcs->atomic_get_property) {
> > > return connector->funcs->atomic_get_property(connector,
> > > state, property, val);
> > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > > index 47dc53c4a738..e848374dee0b 100644
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
> > > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> > > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
> > >
> > > +static const u32 hdmi_colorformats =
> > > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > > +
> > > +static const u32 dp_colorformats =
> > > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > > +
> > > /*
> > > * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
> > > * Format Table 2-120
> > > @@ -2940,6 +2952,102 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
> > > }
> > > EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
> > >
> > > +/**
> > > + * drm_connector_attach_color_format_property - create and attach color format property
> > > + * @connector: connector to create the color format property on
> > > + * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
> > > + * values the connector supports
> > > + *
> > > + * Called by a driver to create a color format property. The property is
> > > + * attached to the connector automatically on success.
> > > + *
> > > + * @supported_color_formats should only include color formats the connector
> > > + * type can actually support.
> > > + *
> > > + * Returns:
> > > + * 0 on success, negative errno on error
> > > + */
> > > +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> > > + unsigned long supported_color_formats)
> > > +{
> > > + struct drm_device *dev = connector->dev;
> > > + struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
> > > + unsigned int i = 0;
> > > + unsigned long fmt;
> > > +
> > > + if (connector->color_format_property)
> > > + return 0;
> > > +
> > > + if (!supported_color_formats) {
> > > + drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
> > > + connector->base.id, connector->name);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
> > > + drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
> > > + connector->base.id, connector->name);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + switch (connector->connector_type) {
> > > + case DRM_MODE_CONNECTOR_HDMIA:
> > > + case DRM_MODE_CONNECTOR_HDMIB:
> > > + if (supported_color_formats & ~hdmi_colorformats) {
> > > + drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
> > > + connector->base.id, connector->name);
> > > + return -EINVAL;
> > > + }
> > > + break;
> > > + case DRM_MODE_CONNECTOR_DisplayPort:
> > > + case DRM_MODE_CONNECTOR_eDP:
> > > + if (supported_color_formats & ~dp_colorformats) {
> > > + drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
> > > + connector->base.id, connector->name);
> > > + return -EINVAL;
> > > + }
> > > + break;
> > > + }
> > > +
> > > + enum_list[0].name = "AUTO";
> > > + enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
> > > +
> > > + for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
> > > + switch (fmt) {
> > > + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> > > + break;
> > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> > > + break;
> > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> > > + break;
> > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> > > + break;
> > > + default:
> > > + drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
> > > + fmt, connector->base.id, connector->name);
> > > + continue;
> > > + }
> > > + enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
> > > + }
> > > +
> > > + connector->color_format_property =
> > > + drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
> > > + enum_list, i + 1);
> > > +
> > > + if (!connector->color_format_property)
> > > + return -ENOMEM;
> > > +
> > > + drm_object_attach_property(&connector->base, connector->color_format_property,
> > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO);
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(drm_connector_attach_color_format_property);
> > > +
> > > /**
> > > * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
> > > * @old_state: old connector state to compare
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index af8b92d2d5b7..bd549f912b76 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -571,14 +571,102 @@ 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.
> >
> > Is there a reason you propose dropping back to YCbCr 4:2:0 without
> > trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> > beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
>
> On HDMI 4:2:2 is always 12bpc, so it doesn't save any bandwidth
> compared to 8bpc 4:4:4.
It does save bandwidth against 10 or 12bpc RGB 4:4:4.
Or is the implication that max_bpc = 12 and
DRM_CONNECTOR_COLOR_FORMAT_AUTO should drop bpc down to 8 and select
RGB in preference to selecting 4:2:2?
Dave
> --
> Ville Syrjälä
> Intel
On Thu, Mar 26, 2026 at 11:16:12AM +0000, Dave Stevenson wrote:
> On Wed, 25 Mar 2026 at 13:43, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > > On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli
> > > <nicolas.frattaroli@collabora.com> wrote:
> > > >
> > > > 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 options are:
> > > > - auto (setup by default, driver internally picks the color format)
> > > > - rgb
> > > > - ycbcr444
> > > > - ycbcr422
> > > > - ycbcr420
> > > >
> > > > Drivers should advertise from this list which formats they support.
> > > > Together with this list and EDID data from the sink we should be able
> > > > to relay a list of usable color formats to users to pick from.
> > > >
> > > > 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>
> > > > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > > > ---
> > > > drivers/gpu/drm/drm_atomic_helper.c | 5 ++
> > > > drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++
> > > > drivers/gpu/drm/drm_connector.c | 108 ++++++++++++++++++++++++++++++++++++
> > > > include/drm/drm_connector.h | 104 ++++++++++++++++++++++++++++++++++
> > > > 4 files changed, 228 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 26953ed6b53e..b7753454b777 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > > > if (old_connector_state->max_requested_bpc !=
> > > > new_connector_state->max_requested_bpc)
> > > > new_crtc_state->connectors_changed = true;
> > > > +
> > > > + if (old_connector_state->color_format !=
> > > > + new_connector_state->color_format)
> > > > + new_crtc_state->connectors_changed = true;
> > > > +
> > > > }
> > > >
> > > > if (funcs->atomic_check)
> > > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > index 5bd5bf6661df..dee510c85e59 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > @@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> > > > state->privacy_screen_sw_state = val;
> > > > } else if (property == connector->broadcast_rgb_property) {
> > > > state->hdmi.broadcast_rgb = val;
> > > > + } else if (property == connector->color_format_property) {
> > > > + if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
> > > > + drm_dbg_atomic(connector->dev,
> > > > + "[CONNECTOR:%d:%s] unknown color format %llu\n",
> > > > + connector->base.id, connector->name, val);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + state->color_format = val;
> > > > } else if (connector->funcs->atomic_set_property) {
> > > > return connector->funcs->atomic_set_property(connector,
> > > > state, property, val);
> > > > @@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> > > > *val = state->privacy_screen_sw_state;
> > > > } else if (property == connector->broadcast_rgb_property) {
> > > > *val = state->hdmi.broadcast_rgb;
> > > > + } else if (property == connector->color_format_property) {
> > > > + *val = state->color_format;
> > > > } else if (connector->funcs->atomic_get_property) {
> > > > return connector->funcs->atomic_get_property(connector,
> > > > state, property, val);
> > > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > > > index 47dc53c4a738..e848374dee0b 100644
> > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > @@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
> > > > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> > > > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
> > > >
> > > > +static const u32 hdmi_colorformats =
> > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > > > +
> > > > +static const u32 dp_colorformats =
> > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > > > +
> > > > /*
> > > > * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
> > > > * Format Table 2-120
> > > > @@ -2940,6 +2952,102 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
> > > > }
> > > > EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
> > > >
> > > > +/**
> > > > + * drm_connector_attach_color_format_property - create and attach color format property
> > > > + * @connector: connector to create the color format property on
> > > > + * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
> > > > + * values the connector supports
> > > > + *
> > > > + * Called by a driver to create a color format property. The property is
> > > > + * attached to the connector automatically on success.
> > > > + *
> > > > + * @supported_color_formats should only include color formats the connector
> > > > + * type can actually support.
> > > > + *
> > > > + * Returns:
> > > > + * 0 on success, negative errno on error
> > > > + */
> > > > +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> > > > + unsigned long supported_color_formats)
> > > > +{
> > > > + struct drm_device *dev = connector->dev;
> > > > + struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
> > > > + unsigned int i = 0;
> > > > + unsigned long fmt;
> > > > +
> > > > + if (connector->color_format_property)
> > > > + return 0;
> > > > +
> > > > + if (!supported_color_formats) {
> > > > + drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
> > > > + connector->base.id, connector->name);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
> > > > + drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
> > > > + connector->base.id, connector->name);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + switch (connector->connector_type) {
> > > > + case DRM_MODE_CONNECTOR_HDMIA:
> > > > + case DRM_MODE_CONNECTOR_HDMIB:
> > > > + if (supported_color_formats & ~hdmi_colorformats) {
> > > > + drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
> > > > + connector->base.id, connector->name);
> > > > + return -EINVAL;
> > > > + }
> > > > + break;
> > > > + case DRM_MODE_CONNECTOR_DisplayPort:
> > > > + case DRM_MODE_CONNECTOR_eDP:
> > > > + if (supported_color_formats & ~dp_colorformats) {
> > > > + drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
> > > > + connector->base.id, connector->name);
> > > > + return -EINVAL;
> > > > + }
> > > > + break;
> > > > + }
> > > > +
> > > > + enum_list[0].name = "AUTO";
> > > > + enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
> > > > +
> > > > + for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
> > > > + switch (fmt) {
> > > > + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> > > > + break;
> > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> > > > + break;
> > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> > > > + break;
> > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> > > > + break;
> > > > + default:
> > > > + drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
> > > > + fmt, connector->base.id, connector->name);
> > > > + continue;
> > > > + }
> > > > + enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
> > > > + }
> > > > +
> > > > + connector->color_format_property =
> > > > + drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
> > > > + enum_list, i + 1);
> > > > +
> > > > + if (!connector->color_format_property)
> > > > + return -ENOMEM;
> > > > +
> > > > + drm_object_attach_property(&connector->base, connector->color_format_property,
> > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(drm_connector_attach_color_format_property);
> > > > +
> > > > /**
> > > > * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
> > > > * @old_state: old connector state to compare
> > > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > > index af8b92d2d5b7..bd549f912b76 100644
> > > > --- a/include/drm/drm_connector.h
> > > > +++ b/include/drm/drm_connector.h
> > > > @@ -571,14 +571,102 @@ 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.
> > >
> > > Is there a reason you propose dropping back to YCbCr 4:2:0 without
> > > trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> > > beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
> >
> > On HDMI 4:2:2 is always 12bpc, so it doesn't save any bandwidth
> > compared to 8bpc 4:4:4.
>
> It does save bandwidth against 10 or 12bpc RGB 4:4:4.
>
> Or is the implication that max_bpc = 12 and
> DRM_CONNECTOR_COLOR_FORMAT_AUTO should drop bpc down to 8 and select
> RGB in preference to selecting 4:2:2?
Yeah, YCbCr has all kinds of extra complications compared to RGB, so
the policy is to use RGB if possible, and only fall back to YCbCr as a
last resort. And in that case 4:2:0 is the only thing that can help.
--
Ville Syrjälä
Intel
On Thu, 26 Mar 2026 at 12:13, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Thu, Mar 26, 2026 at 11:16:12AM +0000, Dave Stevenson wrote:
> > On Wed, 25 Mar 2026 at 13:43, Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > > > On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli
> > > > <nicolas.frattaroli@collabora.com> wrote:
> > > > >
> > > > > 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 options are:
> > > > > - auto (setup by default, driver internally picks the color format)
> > > > > - rgb
> > > > > - ycbcr444
> > > > > - ycbcr422
> > > > > - ycbcr420
> > > > >
> > > > > Drivers should advertise from this list which formats they support.
> > > > > Together with this list and EDID data from the sink we should be able
> > > > > to relay a list of usable color formats to users to pick from.
> > > > >
> > > > > 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>
> > > > > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > > > > ---
> > > > > drivers/gpu/drm/drm_atomic_helper.c | 5 ++
> > > > > drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++
> > > > > drivers/gpu/drm/drm_connector.c | 108 ++++++++++++++++++++++++++++++++++++
> > > > > include/drm/drm_connector.h | 104 ++++++++++++++++++++++++++++++++++
> > > > > 4 files changed, 228 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > index 26953ed6b53e..b7753454b777 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > @@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > > > > if (old_connector_state->max_requested_bpc !=
> > > > > new_connector_state->max_requested_bpc)
> > > > > new_crtc_state->connectors_changed = true;
> > > > > +
> > > > > + if (old_connector_state->color_format !=
> > > > > + new_connector_state->color_format)
> > > > > + new_crtc_state->connectors_changed = true;
> > > > > +
> > > > > }
> > > > >
> > > > > if (funcs->atomic_check)
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > index 5bd5bf6661df..dee510c85e59 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > @@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> > > > > state->privacy_screen_sw_state = val;
> > > > > } else if (property == connector->broadcast_rgb_property) {
> > > > > state->hdmi.broadcast_rgb = val;
> > > > > + } else if (property == connector->color_format_property) {
> > > > > + if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
> > > > > + drm_dbg_atomic(connector->dev,
> > > > > + "[CONNECTOR:%d:%s] unknown color format %llu\n",
> > > > > + connector->base.id, connector->name, val);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + state->color_format = val;
> > > > > } else if (connector->funcs->atomic_set_property) {
> > > > > return connector->funcs->atomic_set_property(connector,
> > > > > state, property, val);
> > > > > @@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> > > > > *val = state->privacy_screen_sw_state;
> > > > > } else if (property == connector->broadcast_rgb_property) {
> > > > > *val = state->hdmi.broadcast_rgb;
> > > > > + } else if (property == connector->color_format_property) {
> > > > > + *val = state->color_format;
> > > > > } else if (connector->funcs->atomic_get_property) {
> > > > > return connector->funcs->atomic_get_property(connector,
> > > > > state, property, val);
> > > > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > > > > index 47dc53c4a738..e848374dee0b 100644
> > > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > > @@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
> > > > > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> > > > > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
> > > > >
> > > > > +static const u32 hdmi_colorformats =
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > > > > +
> > > > > +static const u32 dp_colorformats =
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > > > > +
> > > > > /*
> > > > > * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
> > > > > * Format Table 2-120
> > > > > @@ -2940,6 +2952,102 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
> > > > > }
> > > > > EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
> > > > >
> > > > > +/**
> > > > > + * drm_connector_attach_color_format_property - create and attach color format property
> > > > > + * @connector: connector to create the color format property on
> > > > > + * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
> > > > > + * values the connector supports
> > > > > + *
> > > > > + * Called by a driver to create a color format property. The property is
> > > > > + * attached to the connector automatically on success.
> > > > > + *
> > > > > + * @supported_color_formats should only include color formats the connector
> > > > > + * type can actually support.
> > > > > + *
> > > > > + * Returns:
> > > > > + * 0 on success, negative errno on error
> > > > > + */
> > > > > +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> > > > > + unsigned long supported_color_formats)
> > > > > +{
> > > > > + struct drm_device *dev = connector->dev;
> > > > > + struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
> > > > > + unsigned int i = 0;
> > > > > + unsigned long fmt;
> > > > > +
> > > > > + if (connector->color_format_property)
> > > > > + return 0;
> > > > > +
> > > > > + if (!supported_color_formats) {
> > > > > + drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
> > > > > + drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + switch (connector->connector_type) {
> > > > > + case DRM_MODE_CONNECTOR_HDMIA:
> > > > > + case DRM_MODE_CONNECTOR_HDMIB:
> > > > > + if (supported_color_formats & ~hdmi_colorformats) {
> > > > > + drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > + break;
> > > > > + case DRM_MODE_CONNECTOR_DisplayPort:
> > > > > + case DRM_MODE_CONNECTOR_eDP:
> > > > > + if (supported_color_formats & ~dp_colorformats) {
> > > > > + drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > + break;
> > > > > + }
> > > > > +
> > > > > + enum_list[0].name = "AUTO";
> > > > > + enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
> > > > > +
> > > > > + for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
> > > > > + switch (fmt) {
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> > > > > + break;
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> > > > > + break;
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> > > > > + break;
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> > > > > + break;
> > > > > + default:
> > > > > + drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
> > > > > + fmt, connector->base.id, connector->name);
> > > > > + continue;
> > > > > + }
> > > > > + enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
> > > > > + }
> > > > > +
> > > > > + connector->color_format_property =
> > > > > + drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
> > > > > + enum_list, i + 1);
> > > > > +
> > > > > + if (!connector->color_format_property)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + drm_object_attach_property(&connector->base, connector->color_format_property,
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_connector_attach_color_format_property);
> > > > > +
> > > > > /**
> > > > > * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
> > > > > * @old_state: old connector state to compare
> > > > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > > > index af8b92d2d5b7..bd549f912b76 100644
> > > > > --- a/include/drm/drm_connector.h
> > > > > +++ b/include/drm/drm_connector.h
> > > > > @@ -571,14 +571,102 @@ 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.
> > > >
> > > > Is there a reason you propose dropping back to YCbCr 4:2:0 without
> > > > trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> > > > beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
> > >
> > > On HDMI 4:2:2 is always 12bpc, so it doesn't save any bandwidth
> > > compared to 8bpc 4:4:4.
> >
> > It does save bandwidth against 10 or 12bpc RGB 4:4:4.
> >
> > Or is the implication that max_bpc = 12 and
> > DRM_CONNECTOR_COLOR_FORMAT_AUTO should drop bpc down to 8 and select
> > RGB in preference to selecting 4:2:2?
>
> Yeah, YCbCr has all kinds of extra complications compared to RGB, so
> the policy is to use RGB if possible, and only fall back to YCbCr as a
> last resort. And in that case 4:2:0 is the only thing that can help.
So a media player wanting to do 12bpc HDR playback at 4k60 over HDMI
2.0 ends up with 8bpc RGB regardless. That sucks.
I guess at least an override is being added so userspace can take control.
I'd missed that vc4 had its behaviour changed with the
drm_hdmi_state_helper update :-(
Dave
Hi Dave,
On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index af8b92d2d5b7..bd549f912b76 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -571,14 +571,102 @@ 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.
>
> Is there a reason you propose dropping back to YCbCr 4:2:0 without
> trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
The "auto" behaviour is strictly identical to the one we have right now,
and this one stems from i915. Back when all that logic was added, it was
decided to align every driver behavior on i915 because that's what most
compositors would expect.
Maxime
On Wednesday, 25 March 2026 14:05:25 Central European Standard Time Maxime Ripard wrote:
> Hi Dave,
>
> On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index af8b92d2d5b7..bd549f912b76 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -571,14 +571,102 @@ 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.
> >
> > Is there a reason you propose dropping back to YCbCr 4:2:0 without
> > trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> > beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
>
> The "auto" behaviour is strictly identical to the one we have right now,
> and this one stems from i915. Back when all that logic was added, it was
> decided to align every driver behavior on i915 because that's what most
> compositors would expect.
Hi Maxime,
would it be okay to extend the behavior while we're at it? 4:2:2 does save
bandwidth compared to RGB (unlike YCbCr 4:4:4). I do think 4:2:2 instead of
4:2:0 will provide benefits in some cases. I assume hardware that supports
4:2:2 only instead of 4:2:0 does so in order to save >= 1 horizontal
row of local SRAM buffer in the display controller for any downscaling,
as it'll only need to consider neighbouring pixels on the same row.
Kind regards,
Nicolas Frattaroli
>
> Maxime
>
On Wed, Mar 25, 2026 at 02:21:24PM +0100, Nicolas Frattaroli wrote:
> On Wednesday, 25 March 2026 14:05:25 Central European Standard Time Maxime Ripard wrote:
> > Hi Dave,
> >
> > On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > > index af8b92d2d5b7..bd549f912b76 100644
> > > > --- a/include/drm/drm_connector.h
> > > > +++ b/include/drm/drm_connector.h
> > > > @@ -571,14 +571,102 @@ 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.
> > >
> > > Is there a reason you propose dropping back to YCbCr 4:2:0 without
> > > trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> > > beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
> >
> > The "auto" behaviour is strictly identical to the one we have right now,
> > and this one stems from i915. Back when all that logic was added, it was
> > decided to align every driver behavior on i915 because that's what most
> > compositors would expect.
>
> would it be okay to extend the behavior while we're at it? 4:2:2 does save
> bandwidth compared to RGB (unlike YCbCr 4:4:4). I do think 4:2:2 instead of
> 4:2:0 will provide benefits in some cases.
I don't really know, we would need to ask some Wayland/Weston devs as
well, but it sure is something worth discussing.
I wouldn't do it in this series but as a follow-up though.
Maxime
On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> +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
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> + * not subsampled)
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> + * with horizontal subsampling)
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> + * with horizontal and vertical subsampling)
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
Seems like this should document what the quantization range
should be for each format.
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_COUNT: Number of valid connector color
> + * format values in this enum
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_COUNT,
> +};
> +
> +/**
> + * drm_connector_color_format_valid - Validate drm_connector_color_format value
> + * @fmt: value to check against all values of &enum drm_connector_color_format
> + *
> + * Checks whether the passed in value of @fmt is one of the allowable values in
> + * &enum drm_connector_color_format.
> + *
> + * Returns: %true if it's a valid value for the enum, %false otherwise.
> + */
> +static inline bool __pure
> +drm_connector_color_format_valid(enum drm_connector_color_format fmt)
> +{
> + switch (fmt) {
> + case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
> + case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> const char *
> drm_hdmi_connector_get_output_format_name(enum drm_output_color_format fmt);
>
> @@ -1129,6 +1217,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
> *
> @@ -2127,6 +2222,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:
> *
> @@ -2610,6 +2711,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
>
> --
> 2.53.0
--
Ville Syrjälä
Intel
On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > +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
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > + * not subsampled)
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > + * with horizontal subsampling)
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > + * with horizontal and vertical subsampling)
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
>
> Seems like this should document what the quantization range
> should be for each format.
>
I don't think so? If you want per-component bit depth values,
DRM_FORMAT_* defines would be the appropriate values to use. This
enum is more abstract than that, and is there to communicate
YUV vs. RGB and chroma subsampling, with bit depth being handled
by other properties.
If you mean the factor used for subsampling, then that'd only be
relevant if YCBCR410 was supported where one chroma plane isn't
halved but quartered in resolution. I suspect 4:1:0 will never
be added; no digital display protocol standard supports it to my
knowledge, and hopefully none ever will.
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_COUNT: Number of valid connector color
> > + * format values in this enum
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_COUNT,
> > +};
> > +
> > +/**
> > + * drm_connector_color_format_valid - Validate drm_connector_color_format value
> > + * @fmt: value to check against all values of &enum drm_connector_color_format
> > + *
> > + * Checks whether the passed in value of @fmt is one of the allowable values in
> > + * &enum drm_connector_color_format.
> > + *
> > + * Returns: %true if it's a valid value for the enum, %false otherwise.
> > + */
> > +static inline bool __pure
> > +drm_connector_color_format_valid(enum drm_connector_color_format fmt)
> > +{
> > + switch (fmt) {
> > + case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
> > + case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
> > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
> > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
> > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
> > + return true;
> > + default:
> > + return false;
> > + }
> > +}
> > +
> > const char *
> > drm_hdmi_connector_get_output_format_name(enum drm_output_color_format fmt);
> >
> > @@ -1129,6 +1217,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
> > *
> > @@ -2127,6 +2222,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:
> > *
> > @@ -2610,6 +2711,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
> >
>
>
On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > +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
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > +
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > + * not subsampled)
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > +
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > + * with horizontal subsampling)
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > +
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > + * with horizontal and vertical subsampling)
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> >
> > Seems like this should document what the quantization range
> > should be for each format.
> >
>
> I don't think so? If you want per-component bit depth values,
> DRM_FORMAT_* defines would be the appropriate values to use. This
> enum is more abstract than that, and is there to communicate
> YUV vs. RGB and chroma subsampling, with bit depth being handled
> by other properties.
>
> If you mean the factor used for subsampling, then that'd only be
> relevant if YCBCR410 was supported where one chroma plane isn't
> halved but quartered in resolution. I suspect 4:1:0 will never
> be added; no digital display protocol standard supports it to my
> knowledge, and hopefully none ever will.
No, I mean the quantization range (16-235 vs. 0-255 etc).
The i915 behaviour is that YCbCr is always limited range,
RGB can either be full or limited range depending on the
"Broadcast RGB" property and other related factors.
--
Ville Syrjälä
Intel
On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > +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
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > + * not subsampled)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > + * with horizontal subsampling)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > + * with horizontal and vertical subsampling)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > >
> > > Seems like this should document what the quantization range
> > > should be for each format.
> > >
> >
> > I don't think so? If you want per-component bit depth values,
> > DRM_FORMAT_* defines would be the appropriate values to use. This
> > enum is more abstract than that, and is there to communicate
> > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > by other properties.
> >
> > If you mean the factor used for subsampling, then that'd only be
> > relevant if YCBCR410 was supported where one chroma plane isn't
> > halved but quartered in resolution. I suspect 4:1:0 will never
> > be added; no digital display protocol standard supports it to my
> > knowledge, and hopefully none ever will.
>
> No, I mean the quantization range (16-235 vs. 0-255 etc).
>
> The i915 behaviour is that YCbCr is always limited range,
> RGB can either be full or limited range depending on the
> "Broadcast RGB" property and other related factors.
So far the HDMI state has both the format and quantization range as
different fields. I'm not sure we need to document the range in the
format field, maybe only mention it's not part of the format but has a
field of its own?
Maxime
On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > +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
> > > > > + */
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > +
> > > > > + /**
> > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > + * not subsampled)
> > > > > + */
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > +
> > > > > + /**
> > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > + * with horizontal subsampling)
> > > > > + */
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > +
> > > > > + /**
> > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > + * with horizontal and vertical subsampling)
> > > > > + */
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > >
> > > > Seems like this should document what the quantization range
> > > > should be for each format.
> > > >
> > >
> > > I don't think so? If you want per-component bit depth values,
> > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > enum is more abstract than that, and is there to communicate
> > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > by other properties.
> > >
> > > If you mean the factor used for subsampling, then that'd only be
> > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > be added; no digital display protocol standard supports it to my
> > > knowledge, and hopefully none ever will.
> >
> > No, I mean the quantization range (16-235 vs. 0-255 etc).
> >
> > The i915 behaviour is that YCbCr is always limited range,
> > RGB can either be full or limited range depending on the
> > "Broadcast RGB" property and other related factors.
>
> So far the HDMI state has both the format and quantization range as
> different fields. I'm not sure we need to document the range in the
> format field, maybe only mention it's not part of the format but has a
> field of its own?
I think we only have it for RGB (on some drivers only?). For YCbCr
I think the assumption is limited range everywhere.
But I'm not really concerned about documenting struct members.
What I'm talking about is the *uapi* docs. Surely userspace
will want to know what the new property actually does so the
uapi needs to be documented properly. And down the line some
new driver might also implement the wrong behaviour if there
is no clear specification.
So I'm thinking (or perhaps hoping) the rule might be something like:
- YCbCr limited range
- RGB full range if "Broadcast RGB" property is not present
- RGB full or limited range based on the "Broadcast RGB" property
if it's present
I think the "Broadcast RGB" property itself might also be lacking
proper uapi docs, so that may need to be remedied as well.
--
Ville Syrjälä
Intel
On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > +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
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > + * not subsampled)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > + * with horizontal subsampling)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > + * with horizontal and vertical subsampling)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > >
> > > > > Seems like this should document what the quantization range
> > > > > should be for each format.
> > > > >
> > > >
> > > > I don't think so? If you want per-component bit depth values,
> > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > enum is more abstract than that, and is there to communicate
> > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > by other properties.
> > > >
> > > > If you mean the factor used for subsampling, then that'd only be
> > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > be added; no digital display protocol standard supports it to my
> > > > knowledge, and hopefully none ever will.
> > >
> > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > >
> > > The i915 behaviour is that YCbCr is always limited range,
> > > RGB can either be full or limited range depending on the
> > > "Broadcast RGB" property and other related factors.
> >
> > So far the HDMI state has both the format and quantization range as
> > different fields. I'm not sure we need to document the range in the
> > format field, maybe only mention it's not part of the format but has a
> > field of its own?
>
> I think we only have it for RGB (on some drivers only?). For YCbCr
> I think the assumption is limited range everywhere.
>
> But I'm not really concerned about documenting struct members.
> What I'm talking about is the *uapi* docs. Surely userspace
> will want to know what the new property actually does so the
> uapi needs to be documented properly. And down the line some
> new driver might also implement the wrong behaviour if there
> is no clear specification.
Ack
> So I'm thinking (or perhaps hoping) the rule might be something like:
> - YCbCr limited range
> - RGB full range if "Broadcast RGB" property is not present
Isn't it much more complicated than that for HDMI though? My
recollection was that any VIC but VIC1 would be limited range, and
anything else full range?
> - RGB full or limited range based on the "Broadcast RGB" property
> if it's present
>
> I think the "Broadcast RGB" property itself might also be lacking
> proper uapi docs, so that may need to be remedied as well.
I took care of documenting it when merging the HDMI helpers:
https://docs.kernel.org/gpu/drm-kms.html#hdmi-specific-connector-properties
Maxime
On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > +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
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > + * not subsampled)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > + * with horizontal subsampling)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > >
> > > > > > Seems like this should document what the quantization range
> > > > > > should be for each format.
> > > > > >
> > > > >
> > > > > I don't think so? If you want per-component bit depth values,
> > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > enum is more abstract than that, and is there to communicate
> > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > by other properties.
> > > > >
> > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > be added; no digital display protocol standard supports it to my
> > > > > knowledge, and hopefully none ever will.
> > > >
> > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > >
> > > > The i915 behaviour is that YCbCr is always limited range,
> > > > RGB can either be full or limited range depending on the
> > > > "Broadcast RGB" property and other related factors.
> > >
> > > So far the HDMI state has both the format and quantization range as
> > > different fields. I'm not sure we need to document the range in the
> > > format field, maybe only mention it's not part of the format but has a
> > > field of its own?
> >
> > I think we only have it for RGB (on some drivers only?). For YCbCr
> > I think the assumption is limited range everywhere.
> >
> > But I'm not really concerned about documenting struct members.
> > What I'm talking about is the *uapi* docs. Surely userspace
> > will want to know what the new property actually does so the
> > uapi needs to be documented properly. And down the line some
> > new driver might also implement the wrong behaviour if there
> > is no clear specification.
>
> Ack
>
> > So I'm thinking (or perhaps hoping) the rule might be something like:
> > - YCbCr limited range
> > - RGB full range if "Broadcast RGB" property is not present
>
> Isn't it much more complicated than that for HDMI though? My
> recollection was that any VIC but VIC1 would be limited range, and
> anything else full range?
Do we have some driver that implements the CTA-861 CE vs. IT mode
logic but doesn't expose the "Broadcast RGB" property? I was hoping
those would always go hand in hand now.
>
> > - RGB full or limited range based on the "Broadcast RGB" property
> > if it's present
> >
> > I think the "Broadcast RGB" property itself might also be lacking
> > proper uapi docs, so that may need to be remedied as well.
>
> I took care of documenting it when merging the HDMI helpers:
> https://docs.kernel.org/gpu/drm-kms.html#hdmi-specific-connector-properties
>
> Maxime
--
Ville Syrjälä
Intel
On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > +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
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > + * not subsampled)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > + * with horizontal subsampling)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > >
> > > > > > > Seems like this should document what the quantization range
> > > > > > > should be for each format.
> > > > > > >
> > > > > >
> > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > enum is more abstract than that, and is there to communicate
> > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > by other properties.
> > > > > >
> > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > be added; no digital display protocol standard supports it to my
> > > > > > knowledge, and hopefully none ever will.
> > > > >
> > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > >
> > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > RGB can either be full or limited range depending on the
> > > > > "Broadcast RGB" property and other related factors.
> > > >
> > > > So far the HDMI state has both the format and quantization range as
> > > > different fields. I'm not sure we need to document the range in the
> > > > format field, maybe only mention it's not part of the format but has a
> > > > field of its own?
> > >
> > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > I think the assumption is limited range everywhere.
> > >
> > > But I'm not really concerned about documenting struct members.
> > > What I'm talking about is the *uapi* docs. Surely userspace
> > > will want to know what the new property actually does so the
> > > uapi needs to be documented properly. And down the line some
> > > new driver might also implement the wrong behaviour if there
> > > is no clear specification.
> >
> > Ack
> >
> > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > - YCbCr limited range
> > > - RGB full range if "Broadcast RGB" property is not present
> >
> > Isn't it much more complicated than that for HDMI though? My
> > recollection was that any VIC but VIC1 would be limited range, and
> > anything else full range?
>
> Do we have some driver that implements the CTA-861 CE vs. IT mode
> logic but doesn't expose the "Broadcast RGB" property? I was hoping
> those would always go hand in hand now.
I'm not sure. i915 and the HDMI state helpers handle it properly (I
think?) but it looks like only vc4 registers the Broadcast RGB property
and uses the HDMI state helpers.
And it looks like amdgpu registers Broadcast RGB but doesn't use
drm_default_rgb_quant_range() which seems suspicious?
Maxime
On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > +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
> > > > > > > > > + */
> > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > +
> > > > > > > > > + /**
> > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > + * not subsampled)
> > > > > > > > > + */
> > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > +
> > > > > > > > > + /**
> > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > + */
> > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > +
> > > > > > > > > + /**
> > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > + */
> > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > >
> > > > > > > > Seems like this should document what the quantization range
> > > > > > > > should be for each format.
> > > > > > > >
> > > > > > >
> > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > by other properties.
> > > > > > >
> > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > knowledge, and hopefully none ever will.
> > > > > >
> > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > >
> > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > RGB can either be full or limited range depending on the
> > > > > > "Broadcast RGB" property and other related factors.
> > > > >
> > > > > So far the HDMI state has both the format and quantization range as
> > > > > different fields. I'm not sure we need to document the range in the
> > > > > format field, maybe only mention it's not part of the format but has a
> > > > > field of its own?
> > > >
> > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > I think the assumption is limited range everywhere.
> > > >
> > > > But I'm not really concerned about documenting struct members.
> > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > will want to know what the new property actually does so the
> > > > uapi needs to be documented properly. And down the line some
> > > > new driver might also implement the wrong behaviour if there
> > > > is no clear specification.
> > >
> > > Ack
> > >
> > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > - YCbCr limited range
> > > > - RGB full range if "Broadcast RGB" property is not present
> > >
> > > Isn't it much more complicated than that for HDMI though? My
> > > recollection was that any VIC but VIC1 would be limited range, and
> > > anything else full range?
> >
> > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > those would always go hand in hand now.
>
> I'm not sure. i915 and the HDMI state helpers handle it properly (I
> think?) but it looks like only vc4 registers the Broadcast RGB property
> and uses the HDMI state helpers.
>
> And it looks like amdgpu registers Broadcast RGB but doesn't use
> drm_default_rgb_quant_range() which seems suspicious?
If they want just manual full vs. limited then they should
limit the property to not expose the "auto" option at all.
amdgpu also ties this in with the "colorspace" property, which
originally in i915 only controlled the infoframes/etc. But on
amdgpu it now controls various aspects of output color
transformation. The end result is that the property is a complete
mess with most of the values making no sense. And for whatever
reason everyone involved refused to remove/deprecate the
nonsensical values :/
Looks like this series should make sure the documentation for
the "colorspace" property is in sync with the new property
as well. Currently now it's giving conflicting information.
--
Ville Syrjälä
Intel
On Thu, Mar 26, 2026 at 07:58:25PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > +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
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > + * not subsampled)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > >
> > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > should be for each format.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > by other properties.
> > > > > > > >
> > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > knowledge, and hopefully none ever will.
> > > > > > >
> > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > >
> > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > RGB can either be full or limited range depending on the
> > > > > > > "Broadcast RGB" property and other related factors.
> > > > > >
> > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > field of its own?
> > > > >
> > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > I think the assumption is limited range everywhere.
> > > > >
> > > > > But I'm not really concerned about documenting struct members.
> > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > will want to know what the new property actually does so the
> > > > > uapi needs to be documented properly. And down the line some
> > > > > new driver might also implement the wrong behaviour if there
> > > > > is no clear specification.
> > > >
> > > > Ack
> > > >
> > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > - YCbCr limited range
> > > > > - RGB full range if "Broadcast RGB" property is not present
> > > >
> > > > Isn't it much more complicated than that for HDMI though? My
> > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > anything else full range?
> > >
> > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > those would always go hand in hand now.
> >
> > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > think?) but it looks like only vc4 registers the Broadcast RGB property
> > and uses the HDMI state helpers.
> >
> > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > drm_default_rgb_quant_range() which seems suspicious?
>
> If they want just manual full vs. limited then they should
> limit the property to not expose the "auto" option at all.
>
> amdgpu also ties this in with the "colorspace" property, which
> originally in i915 only controlled the infoframes/etc. But on
> amdgpu it now controls various aspects of output color
> transformation. The end result is that the property is a complete
> mess with most of the values making no sense. And for whatever
> reason everyone involved refused to remove/deprecate the
> nonsensical values :/
>
> Looks like this series should make sure the documentation for
> the "colorspace" property is in sync with the new property
> as well. Currently now it's giving conflicting information.
After pondering about this a bit more I guess we could actually
use this to make all the values of the colorspace property make
some sense.
Since we won't have to worry about that RGB->YCbCr 4:2:0
fallback when using and explicit color format, all we'd have
to do is explicitly reject the nonsensical combinations:
color_format_and_colorspace_ok()
{
switch (color_format) {
case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
switch (colorspace) {
case DRM_MODE_COLORIMETRY_NO_DATA:
case DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
case DRM_MODE_COLORIMETRY_BT601_YCC:
case DRM_MODE_COLORIMETRY_BT709_YCC:
case DRM_MODE_COLORIMETRY_XVYCC_601:
case DRM_MODE_COLORIMETRY_XVYCC_709:
case DRM_MODE_COLORIMETRY_SYCC_601:
case DRM_MODE_COLORIMETRY_OPYCC_601:
case DRM_MODE_COLORIMETRY_BT2020_CYCC:
case DRM_MODE_COLORIMETRY_BT2020_YCC:
case DRM_MODE_COLORIMETRY_BT709_YCC:
return true;
default:
return false;
}
break;
case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
switch (colorspace) {
case DRM_MODE_COLORIMETRY_NO_DATA:
case DRM_MODE_COLORIMETRY_OPRGB:
case DRM_MODE_COLORIMETRY_BT2020_RGB:
case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
case DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
case DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
case DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
case DRM_MODE_COLORIMETRY_OPRGB:
case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
case DRM_MODE_COLORIMETRY_BT2020_RGB:
return true;
default
return false;
}
break;
case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
switch (colorspace) {
case DRM_MODE_COLORIMETRY_NO_DATA:
case DRM_MODE_COLORIMETRY_BT2020_RGB:
case DRM_MODE_COLORIMETRY_BT2020_YCC:
return true;
default:
return false;
}
default:
bad;
}
}
And then presumably the colorspace property is the thing that should
dictate which conversion matrix to use. So something like this:
csc_matrix()
{
switch (colorspace) {
case DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
case DRM_MODE_COLORIMETRY_BT601_YCC:
case DRM_MODE_COLORIMETRY_XVYCC_601:
case DRM_MODE_COLORIMETRY_SYCC_601:
case DRM_MODE_COLORIMETRY_OPYCC_601:
return 601;
case DRM_MODE_COLORIMETRY_BT709_YCC:
case DRM_MODE_COLORIMETRY_XVYCC_709:
return 709;
case DRM_MODE_COLORIMETRY_BT2020_YCC:
case DRM_MODE_COLORIMETRY_BT2020_RGB:
return 2020;
case DRM_MODE_COLORIMETRY_BT2020_CYCC:
return 2020_const;
case DRM_MODE_COLORIMETRY_NO_DATA:
return vdisplay >= 720 ? 709 : 601;
default:
bad;
}
}
--
Ville Syrjälä
Intel
On Sat, 28 Mar 2026 02:22:01 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Thu, Mar 26, 2026 at 07:58:25PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > +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
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > > +
> > > > > > > > > > > + /**
> > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > > + * not subsampled)
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > > +
> > > > > > > > > > > + /**
> > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > > +
> > > > > > > > > > > + /**
> > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > > >
> > > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > > should be for each format.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > > by other properties.
> > > > > > > > >
> > > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > > knowledge, and hopefully none ever will.
> > > > > > > >
> > > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > > >
> > > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > > RGB can either be full or limited range depending on the
> > > > > > > > "Broadcast RGB" property and other related factors.
> > > > > > >
> > > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > > field of its own?
> > > > > >
> > > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > > I think the assumption is limited range everywhere.
> > > > > >
> > > > > > But I'm not really concerned about documenting struct members.
> > > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > > will want to know what the new property actually does so the
> > > > > > uapi needs to be documented properly. And down the line some
> > > > > > new driver might also implement the wrong behaviour if there
> > > > > > is no clear specification.
> > > > >
> > > > > Ack
> > > > >
> > > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > > - YCbCr limited range
> > > > > > - RGB full range if "Broadcast RGB" property is not present
> > > > >
> > > > > Isn't it much more complicated than that for HDMI though? My
> > > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > > anything else full range?
> > > >
> > > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > > those would always go hand in hand now.
> > >
> > > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > > think?) but it looks like only vc4 registers the Broadcast RGB property
> > > and uses the HDMI state helpers.
> > >
> > > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > > drm_default_rgb_quant_range() which seems suspicious?
> >
> > If they want just manual full vs. limited then they should
> > limit the property to not expose the "auto" option at all.
> >
> > amdgpu also ties this in with the "colorspace" property, which
> > originally in i915 only controlled the infoframes/etc. But on
> > amdgpu it now controls various aspects of output color
> > transformation. The end result is that the property is a complete
> > mess with most of the values making no sense. And for whatever
> > reason everyone involved refused to remove/deprecate the
> > nonsensical values :/
> >
> > Looks like this series should make sure the documentation for
> > the "colorspace" property is in sync with the new property
> > as well. Currently now it's giving conflicting information.
>
> After pondering about this a bit more I guess we could actually
> use this to make all the values of the colorspace property make
> some sense.
>
> Since we won't have to worry about that RGB->YCbCr 4:2:0
> fallback when using and explicit color format, all we'd have
> to do is explicitly reject the nonsensical combinations:
>
> color_format_and_colorspace_ok()
> {
> switch (color_format) {
> case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
> case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
> case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
> switch (colorspace) {
> case DRM_MODE_COLORIMETRY_NO_DATA:
> case DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
> case DRM_MODE_COLORIMETRY_BT601_YCC:
> case DRM_MODE_COLORIMETRY_BT709_YCC:
> case DRM_MODE_COLORIMETRY_XVYCC_601:
> case DRM_MODE_COLORIMETRY_XVYCC_709:
> case DRM_MODE_COLORIMETRY_SYCC_601:
> case DRM_MODE_COLORIMETRY_OPYCC_601:
> case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> case DRM_MODE_COLORIMETRY_BT2020_YCC:
> case DRM_MODE_COLORIMETRY_BT709_YCC:
> return true;
> default:
> return false;
> }
> break;
> case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
> switch (colorspace) {
> case DRM_MODE_COLORIMETRY_NO_DATA:
> case DRM_MODE_COLORIMETRY_OPRGB:
> case DRM_MODE_COLORIMETRY_BT2020_RGB:
> case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
> case DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
> case DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
> case DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
> case DRM_MODE_COLORIMETRY_OPRGB:
> case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
> case DRM_MODE_COLORIMETRY_BT2020_RGB:
> return true;
> default
> return false;
> }
> break;
> case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
> switch (colorspace) {
> case DRM_MODE_COLORIMETRY_NO_DATA:
> case DRM_MODE_COLORIMETRY_BT2020_RGB:
> case DRM_MODE_COLORIMETRY_BT2020_YCC:
> return true;
> default:
> return false;
> }
> default:
> bad;
> }
> }
>
> And then presumably the colorspace property is the thing that should
> dictate which conversion matrix to use. So something like this:
>
> csc_matrix()
> {
> switch (colorspace) {
> case DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
> case DRM_MODE_COLORIMETRY_BT601_YCC:
> case DRM_MODE_COLORIMETRY_XVYCC_601:
> case DRM_MODE_COLORIMETRY_SYCC_601:
> case DRM_MODE_COLORIMETRY_OPYCC_601:
> return 601;
> case DRM_MODE_COLORIMETRY_BT709_YCC:
> case DRM_MODE_COLORIMETRY_XVYCC_709:
> return 709;
> case DRM_MODE_COLORIMETRY_BT2020_YCC:
> case DRM_MODE_COLORIMETRY_BT2020_RGB:
> return 2020;
> case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> return 2020_const;
> case DRM_MODE_COLORIMETRY_NO_DATA:
> return vdisplay >= 720 ? 709 : 601;
> default:
> bad;
> }
> }
>
Hi Ville,
I believe the RGB-to-YCbCr matrix choice belongs in a colorop in the
CRTC color pipeline. It would be really nice to let go of the
requirement that the KMS color pipeline can be only in full-range RGB.
I imagine being able to scan out a YCbCr limited range buffer as-is
would be really useful for professional broadcasting industry and
particularly PLUGE testing which relies on being able to send the
sub-black and super-white YCbCr values for monitor calibration.
However, if there is an "auto" value in the colorop (implies the
input to the colorop must be full-range RGB) or the colorop is missing,
then your proposal could be used there.
Thanks,
pq
On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > +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
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > + * not subsampled)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > >
> > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > should be for each format.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > by other properties.
> > > > > > > >
> > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > knowledge, and hopefully none ever will.
> > > > > > >
> > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > >
> > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > RGB can either be full or limited range depending on the
> > > > > > > "Broadcast RGB" property and other related factors.
> > > > > >
> > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > field of its own?
> > > > >
> > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > I think the assumption is limited range everywhere.
> > > > >
> > > > > But I'm not really concerned about documenting struct members.
> > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > will want to know what the new property actually does so the
> > > > > uapi needs to be documented properly. And down the line some
> > > > > new driver might also implement the wrong behaviour if there
> > > > > is no clear specification.
> > > >
> > > > Ack
> > > >
> > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > - YCbCr limited range
> > > > > - RGB full range if "Broadcast RGB" property is not present
> > > >
> > > > Isn't it much more complicated than that for HDMI though? My
> > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > anything else full range?
> > >
> > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > those would always go hand in hand now.
> >
> > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > think?) but it looks like only vc4 registers the Broadcast RGB property
> > and uses the HDMI state helpers.
> >
> > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > drm_default_rgb_quant_range() which seems suspicious?
>
> If they want just manual full vs. limited then they should
> limit the property to not expose the "auto" option at all.
>
> amdgpu also ties this in with the "colorspace" property, which
> originally in i915 only controlled the infoframes/etc. But on
> amdgpu it now controls various aspects of output color
> transformation. The end result is that the property is a complete
> mess with most of the values making no sense. And for whatever
> reason everyone involved refused to remove/deprecate the
> nonsensical values :/
>
> Looks like this series should make sure the documentation for
> the "colorspace" property is in sync with the new property
> as well. Currently now it's giving conflicting information.
>
I take it the problematic information is in
* DOC: standard connector properties
*
* Colorspace:
and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
that they "produce RGB content".
I think we probably just have to change the statement "The variants
BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
RGB and YCbCr on its own."
The "on its own" here would get turned into "based on the color format
property".
Speaking of i915, that patch is one of the very few (5) patches in
this series still lacking a review (hint hint nudge nudge). I'd like
to get some more feedback on the remaining patches before I send out
another revision, so that it's hopefully not just docs changes (I
know better than to think those patches must be perfect and won't
need revision.)
If `drm/bridge: Act on the DRM color format property` and
`drm/atomic-helper: Add HDMI bridge output bus formats helper` get a
reviewed-by/acked-by and it's still crickets on the amdgpu and i915
front, then I will just drop the amdgpu/i915 implementations so that
they don't block this from landing.
Kind regards,
Nicolas Frattaroli
On Fri, Mar 27, 2026 at 01:56:06PM +0100, Nicolas Frattaroli wrote:
> On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > +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
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > > +
> > > > > > > > > > > + /**
> > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > > + * not subsampled)
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > > +
> > > > > > > > > > > + /**
> > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > > +
> > > > > > > > > > > + /**
> > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > > >
> > > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > > should be for each format.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > > by other properties.
> > > > > > > > >
> > > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > > knowledge, and hopefully none ever will.
> > > > > > > >
> > > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > > >
> > > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > > RGB can either be full or limited range depending on the
> > > > > > > > "Broadcast RGB" property and other related factors.
> > > > > > >
> > > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > > field of its own?
> > > > > >
> > > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > > I think the assumption is limited range everywhere.
> > > > > >
> > > > > > But I'm not really concerned about documenting struct members.
> > > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > > will want to know what the new property actually does so the
> > > > > > uapi needs to be documented properly. And down the line some
> > > > > > new driver might also implement the wrong behaviour if there
> > > > > > is no clear specification.
> > > > >
> > > > > Ack
> > > > >
> > > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > > - YCbCr limited range
> > > > > > - RGB full range if "Broadcast RGB" property is not present
> > > > >
> > > > > Isn't it much more complicated than that for HDMI though? My
> > > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > > anything else full range?
> > > >
> > > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > > those would always go hand in hand now.
> > >
> > > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > > think?) but it looks like only vc4 registers the Broadcast RGB property
> > > and uses the HDMI state helpers.
> > >
> > > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > > drm_default_rgb_quant_range() which seems suspicious?
> >
> > If they want just manual full vs. limited then they should
> > limit the property to not expose the "auto" option at all.
> >
> > amdgpu also ties this in with the "colorspace" property, which
> > originally in i915 only controlled the infoframes/etc. But on
> > amdgpu it now controls various aspects of output color
> > transformation. The end result is that the property is a complete
> > mess with most of the values making no sense. And for whatever
> > reason everyone involved refused to remove/deprecate the
> > nonsensical values :/
> >
> > Looks like this series should make sure the documentation for
> > the "colorspace" property is in sync with the new property
> > as well. Currently now it's giving conflicting information.
> >
>
> I take it the problematic information is in
>
> * DOC: standard connector properties
> *
> * Colorspace:
>
> and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
> that they "produce RGB content".
>
> I think we probably just have to change the statement "The variants
> BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
> RGB and YCbCr on its own."
>
> The "on its own" here would get turned into "based on the color format
> property".
>
> Speaking of i915, that patch is one of the very few (5) patches in
> this series still lacking a review (hint hint nudge nudge). I'd like
> to get some more feedback on the remaining patches before I send out
> another revision, so that it's hopefully not just docs changes (I
> know better than to think those patches must be perfect and won't
> need revision.)
The i915 code around this is already a big mess, and I don't really
adding to that mess. So I think we'll need to do some refactoring before
we add anything there. I already started typing something and so far
it looks fairly straightforward, so I should have something soon.
While doing that several questions came to my mind though:
* More interactions with the colorspace property, but I sent
a separate mail already about that
* Which conversion matrix to use, and the answer I suspect
should be "ask the colorspace property", as mentioned in the
other mail
* Should we flat out reject color formats (and I suppose also
colorspace prop values) the sink doesn't claim to support?
If yes, then I think we'll have to forget about adding anything
to i915 MST code. The way the MST stuff works is that if one
stream needs a modeset then all the related streams get modeset
as well. Thus if the user replaces a monitor getting fed with a
YCbCr stream just as another stream is being modeset, then the
entire atomic commit could fail due to the YCbCr stream getting
rejected.
I think eventually we might have to invent some mechanism where
all the input into the modeset computation is cached somehow,
and said cache updated only on explicit userspace modesets.
Either that or we have to come up with a way to skip some of
the calculations that depend on external factors. Either way
it's going to be a pain.
OTOH if we don't mind feeding the sink with stuff it can't
understand, then I suppose we might add YCbCr 4:4:4 support
for MST. It shouldn't be any different from RGB apart from
the RGB->YCbCr conversion, which is handled elsewhere. But
YCbCr 4:2:0 is definitely out either way, the MST code has
no support for that currently.
--
Ville Syrjälä
Intel
On Sat, Mar 28, 2026 at 02:49:04AM +0200, Ville Syrjälä wrote:
> On Fri, Mar 27, 2026 at 01:56:06PM +0100, Nicolas Frattaroli wrote:
> > On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> > > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > > +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
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > > > + * not subsampled)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > > > >
> > > > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > > > should be for each format.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > > > by other properties.
> > > > > > > > > >
> > > > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > > > knowledge, and hopefully none ever will.
> > > > > > > > >
> > > > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > > > >
> > > > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > > > RGB can either be full or limited range depending on the
> > > > > > > > > "Broadcast RGB" property and other related factors.
> > > > > > > >
> > > > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > > > field of its own?
> > > > > > >
> > > > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > > > I think the assumption is limited range everywhere.
> > > > > > >
> > > > > > > But I'm not really concerned about documenting struct members.
> > > > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > > > will want to know what the new property actually does so the
> > > > > > > uapi needs to be documented properly. And down the line some
> > > > > > > new driver might also implement the wrong behaviour if there
> > > > > > > is no clear specification.
> > > > > >
> > > > > > Ack
> > > > > >
> > > > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > > > - YCbCr limited range
> > > > > > > - RGB full range if "Broadcast RGB" property is not present
> > > > > >
> > > > > > Isn't it much more complicated than that for HDMI though? My
> > > > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > > > anything else full range?
> > > > >
> > > > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > > > those would always go hand in hand now.
> > > >
> > > > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > > > think?) but it looks like only vc4 registers the Broadcast RGB property
> > > > and uses the HDMI state helpers.
> > > >
> > > > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > > > drm_default_rgb_quant_range() which seems suspicious?
> > >
> > > If they want just manual full vs. limited then they should
> > > limit the property to not expose the "auto" option at all.
> > >
> > > amdgpu also ties this in with the "colorspace" property, which
> > > originally in i915 only controlled the infoframes/etc. But on
> > > amdgpu it now controls various aspects of output color
> > > transformation. The end result is that the property is a complete
> > > mess with most of the values making no sense. And for whatever
> > > reason everyone involved refused to remove/deprecate the
> > > nonsensical values :/
> > >
> > > Looks like this series should make sure the documentation for
> > > the "colorspace" property is in sync with the new property
> > > as well. Currently now it's giving conflicting information.
> > >
> >
> > I take it the problematic information is in
> >
> > * DOC: standard connector properties
> > *
> > * Colorspace:
> >
> > and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
> > that they "produce RGB content".
> >
> > I think we probably just have to change the statement "The variants
> > BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
> > RGB and YCbCr on its own."
> >
> > The "on its own" here would get turned into "based on the color format
> > property".
> >
> > Speaking of i915, that patch is one of the very few (5) patches in
> > this series still lacking a review (hint hint nudge nudge). I'd like
> > to get some more feedback on the remaining patches before I send out
> > another revision, so that it's hopefully not just docs changes (I
> > know better than to think those patches must be perfect and won't
> > need revision.)
>
> The i915 code around this is already a big mess, and I don't really
> adding to that mess. So I think we'll need to do some refactoring before
> we add anything there. I already started typing something and so far
> it looks fairly straightforward, so I should have something soon.
OK, posted something
https://lore.kernel.org/intel-gfx/20260330235339.29479-1-ville.syrjala@linux.intel.com/T/#m7c349478ca6c856fbc68d5e2178f1aa31678a05f
Are the wayland/compositor/color management folks on board with
these new properties? I don't think I see the usual suspects on
the cc list.
>
> While doing that several questions came to my mind though:
>
> * More interactions with the colorspace property, but I sent
> a separate mail already about that
>
> * Which conversion matrix to use, and the answer I suspect
> should be "ask the colorspace property", as mentioned in the
> other mail
>
> * Should we flat out reject color formats (and I suppose also
> colorspace prop values) the sink doesn't claim to support?
>
> If yes, then I think we'll have to forget about adding anything
> to i915 MST code. The way the MST stuff works is that if one
> stream needs a modeset then all the related streams get modeset
> as well. Thus if the user replaces a monitor getting fed with a
> YCbCr stream just as another stream is being modeset, then the
> entire atomic commit could fail due to the YCbCr stream getting
> rejected.
>
> I think eventually we might have to invent some mechanism where
> all the input into the modeset computation is cached somehow,
> and said cache updated only on explicit userspace modesets.
> Either that or we have to come up with a way to skip some of
> the calculations that depend on external factors. Either way
> it's going to be a pain.
>
> OTOH if we don't mind feeding the sink with stuff it can't
> understand, then I suppose we might add YCbCr 4:4:4 support
> for MST. It shouldn't be any different from RGB apart from
> the RGB->YCbCr conversion, which is handled elsewhere. But
> YCbCr 4:2:0 is definitely out either way, the MST code has
> no support for that currently.
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
On Tuesday, 31 March 2026 01:56:16 Central European Summer Time Ville Syrjälä wrote:
> On Sat, Mar 28, 2026 at 02:49:04AM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 27, 2026 at 01:56:06PM +0100, Nicolas Frattaroli wrote:
> > > On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> > > > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > > > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > > > +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
> > > > > > > > > > > > > + */
> > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + /**
> > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > > > > + * not subsampled)
> > > > > > > > > > > > > + */
> > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + /**
> > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > > > > + */
> > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + /**
> > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > > > > + */
> > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > > > > >
> > > > > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > > > > should be for each format.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > > > > by other properties.
> > > > > > > > > > >
> > > > > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > > > > knowledge, and hopefully none ever will.
> > > > > > > > > >
> > > > > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > > > > >
> > > > > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > > > > RGB can either be full or limited range depending on the
> > > > > > > > > > "Broadcast RGB" property and other related factors.
> > > > > > > > >
> > > > > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > > > > field of its own?
> > > > > > > >
> > > > > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > > > > I think the assumption is limited range everywhere.
> > > > > > > >
> > > > > > > > But I'm not really concerned about documenting struct members.
> > > > > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > > > > will want to know what the new property actually does so the
> > > > > > > > uapi needs to be documented properly. And down the line some
> > > > > > > > new driver might also implement the wrong behaviour if there
> > > > > > > > is no clear specification.
> > > > > > >
> > > > > > > Ack
> > > > > > >
> > > > > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > > > > - YCbCr limited range
> > > > > > > > - RGB full range if "Broadcast RGB" property is not present
> > > > > > >
> > > > > > > Isn't it much more complicated than that for HDMI though? My
> > > > > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > > > > anything else full range?
> > > > > >
> > > > > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > > > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > > > > those would always go hand in hand now.
> > > > >
> > > > > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > > > > think?) but it looks like only vc4 registers the Broadcast RGB property
> > > > > and uses the HDMI state helpers.
> > > > >
> > > > > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > > > > drm_default_rgb_quant_range() which seems suspicious?
> > > >
> > > > If they want just manual full vs. limited then they should
> > > > limit the property to not expose the "auto" option at all.
> > > >
> > > > amdgpu also ties this in with the "colorspace" property, which
> > > > originally in i915 only controlled the infoframes/etc. But on
> > > > amdgpu it now controls various aspects of output color
> > > > transformation. The end result is that the property is a complete
> > > > mess with most of the values making no sense. And for whatever
> > > > reason everyone involved refused to remove/deprecate the
> > > > nonsensical values :/
> > > >
> > > > Looks like this series should make sure the documentation for
> > > > the "colorspace" property is in sync with the new property
> > > > as well. Currently now it's giving conflicting information.
> > > >
> > >
> > > I take it the problematic information is in
> > >
> > > * DOC: standard connector properties
> > > *
> > > * Colorspace:
> > >
> > > and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
> > > that they "produce RGB content".
> > >
> > > I think we probably just have to change the statement "The variants
> > > BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
> > > RGB and YCbCr on its own."
> > >
> > > The "on its own" here would get turned into "based on the color format
> > > property".
> > >
> > > Speaking of i915, that patch is one of the very few (5) patches in
> > > this series still lacking a review (hint hint nudge nudge). I'd like
> > > to get some more feedback on the remaining patches before I send out
> > > another revision, so that it's hopefully not just docs changes (I
> > > know better than to think those patches must be perfect and won't
> > > need revision.)
> >
> > The i915 code around this is already a big mess, and I don't really
> > adding to that mess. So I think we'll need to do some refactoring before
> > we add anything there. I already started typing something and so far
> > it looks fairly straightforward, so I should have something soon.
>
> OK, posted something
> https://lore.kernel.org/intel-gfx/20260330235339.29479-1-ville.syrjala@linux.intel.com/T/#m7c349478ca6c856fbc68d5e2178f1aa31678a05f
Thanks! I'll take a look at this today to get a more solid idea of
where the pain points you highlighted are.
I'll also rebase/reimplement my i915 color format implementation
(sans the DP-MST part, as discussed) on top of this on the next
revision. I was never fully happy with the current one due to the
logic being shoehorned into the already existing i915 fallback
format logic, so I'm quite happy to have another opportunity to
implement it with less historic baggage.
> Are the wayland/compositor/color management folks on board with
> these new properties? I don't think I see the usual suspects on
> the cc list.
I don't know which precise group of people you refer to, but at
least from the Collabora side of things, the userspace Wayland
people are on board with these new properties. In Weston, we use
it to implement the Weston frontend's "color-format" option in a
WIP branch at
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1859
I've also been made aware that LibreELEC is aware, and will look
into making use of it rather than their own kernel patches.
Kind regards,
Nicolas Frattaroli
> >
> > While doing that several questions came to my mind though:
> >
> > * More interactions with the colorspace property, but I sent
> > a separate mail already about that
> >
> > * Which conversion matrix to use, and the answer I suspect
> > should be "ask the colorspace property", as mentioned in the
> > other mail
> >
> > * Should we flat out reject color formats (and I suppose also
> > colorspace prop values) the sink doesn't claim to support?
> >
> > If yes, then I think we'll have to forget about adding anything
> > to i915 MST code. The way the MST stuff works is that if one
> > stream needs a modeset then all the related streams get modeset
> > as well. Thus if the user replaces a monitor getting fed with a
> > YCbCr stream just as another stream is being modeset, then the
> > entire atomic commit could fail due to the YCbCr stream getting
> > rejected.
> >
> > I think eventually we might have to invent some mechanism where
> > all the input into the modeset computation is cached somehow,
> > and said cache updated only on explicit userspace modesets.
> > Either that or we have to come up with a way to skip some of
> > the calculations that depend on external factors. Either way
> > it's going to be a pain.
> >
> > OTOH if we don't mind feeding the sink with stuff it can't
> > understand, then I suppose we might add YCbCr 4:4:4 support
> > for MST. It shouldn't be any different from RGB apart from
> > the RGB->YCbCr conversion, which is handled elsewhere. But
> > YCbCr 4:2:0 is definitely out either way, the MST code has
> > no support for that currently.
> >
>
>
On Tue, Mar 31, 2026 at 12:33:00PM +0200, Nicolas Frattaroli wrote:
> On Tuesday, 31 March 2026 01:56:16 Central European Summer Time Ville Syrjälä wrote:
> > On Sat, Mar 28, 2026 at 02:49:04AM +0200, Ville Syrjälä wrote:
> > > On Fri, Mar 27, 2026 at 01:56:06PM +0100, Nicolas Frattaroli wrote:
> > > > On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> > > > > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > > > > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > > > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > > > > +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
> > > > > > > > > > > > > > + */
> > > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + /**
> > > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > > > > > + * not subsampled)
> > > > > > > > > > > > > > + */
> > > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + /**
> > > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > > > > > + */
> > > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + /**
> > > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > > > > > + */
> > > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > > > > > should be for each format.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > > > > > by other properties.
> > > > > > > > > > > >
> > > > > > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > > > > > knowledge, and hopefully none ever will.
> > > > > > > > > > >
> > > > > > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > > > > > >
> > > > > > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > > > > > RGB can either be full or limited range depending on the
> > > > > > > > > > > "Broadcast RGB" property and other related factors.
> > > > > > > > > >
> > > > > > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > > > > > field of its own?
> > > > > > > > >
> > > > > > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > > > > > I think the assumption is limited range everywhere.
> > > > > > > > >
> > > > > > > > > But I'm not really concerned about documenting struct members.
> > > > > > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > > > > > will want to know what the new property actually does so the
> > > > > > > > > uapi needs to be documented properly. And down the line some
> > > > > > > > > new driver might also implement the wrong behaviour if there
> > > > > > > > > is no clear specification.
> > > > > > > >
> > > > > > > > Ack
> > > > > > > >
> > > > > > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > > > > > - YCbCr limited range
> > > > > > > > > - RGB full range if "Broadcast RGB" property is not present
> > > > > > > >
> > > > > > > > Isn't it much more complicated than that for HDMI though? My
> > > > > > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > > > > > anything else full range?
> > > > > > >
> > > > > > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > > > > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > > > > > those would always go hand in hand now.
> > > > > >
> > > > > > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > > > > > think?) but it looks like only vc4 registers the Broadcast RGB property
> > > > > > and uses the HDMI state helpers.
> > > > > >
> > > > > > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > > > > > drm_default_rgb_quant_range() which seems suspicious?
> > > > >
> > > > > If they want just manual full vs. limited then they should
> > > > > limit the property to not expose the "auto" option at all.
> > > > >
> > > > > amdgpu also ties this in with the "colorspace" property, which
> > > > > originally in i915 only controlled the infoframes/etc. But on
> > > > > amdgpu it now controls various aspects of output color
> > > > > transformation. The end result is that the property is a complete
> > > > > mess with most of the values making no sense. And for whatever
> > > > > reason everyone involved refused to remove/deprecate the
> > > > > nonsensical values :/
> > > > >
> > > > > Looks like this series should make sure the documentation for
> > > > > the "colorspace" property is in sync with the new property
> > > > > as well. Currently now it's giving conflicting information.
> > > > >
> > > >
> > > > I take it the problematic information is in
> > > >
> > > > * DOC: standard connector properties
> > > > *
> > > > * Colorspace:
> > > >
> > > > and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
> > > > that they "produce RGB content".
> > > >
> > > > I think we probably just have to change the statement "The variants
> > > > BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
> > > > RGB and YCbCr on its own."
> > > >
> > > > The "on its own" here would get turned into "based on the color format
> > > > property".
> > > >
> > > > Speaking of i915, that patch is one of the very few (5) patches in
> > > > this series still lacking a review (hint hint nudge nudge). I'd like
> > > > to get some more feedback on the remaining patches before I send out
> > > > another revision, so that it's hopefully not just docs changes (I
> > > > know better than to think those patches must be perfect and won't
> > > > need revision.)
> > >
> > > The i915 code around this is already a big mess, and I don't really
> > > adding to that mess. So I think we'll need to do some refactoring before
> > > we add anything there. I already started typing something and so far
> > > it looks fairly straightforward, so I should have something soon.
> >
> > OK, posted something
> > https://lore.kernel.org/intel-gfx/20260330235339.29479-1-ville.syrjala@linux.intel.com/T/#m7c349478ca6c856fbc68d5e2178f1aa31678a05f
>
> Thanks! I'll take a look at this today to get a more solid idea of
> where the pain points you highlighted are.
>
> I'll also rebase/reimplement my i915 color format implementation
> (sans the DP-MST part, as discussed) on top of this on the next
> revision. I was never fully happy with the current one due to the
> logic being shoehorned into the already existing i915 fallback
> format logic, so I'm quite happy to have another opportunity to
> implement it with less historic baggage.
>
> > Are the wayland/compositor/color management folks on board with
> > these new properties? I don't think I see the usual suspects on
> > the cc list.
>
> I don't know which precise group of people you refer to,
Off the top of my head, Pekka,Simon,Sebastian,Jonas,Xaver might be
relevant here. Added to Cc...
> but at
> least from the Collabora side of things, the userspace Wayland
> people are on board with these new properties. In Weston, we use
> it to implement the Weston frontend's "color-format" option in a
> WIP branch at
>
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1859
>
> I've also been made aware that LibreELEC is aware, and will look
> into making use of it rather than their own kernel patches.
>
> Kind regards,
> Nicolas Frattaroli
>
> > >
> > > While doing that several questions came to my mind though:
> > >
> > > * More interactions with the colorspace property, but I sent
> > > a separate mail already about that
> > >
> > > * Which conversion matrix to use, and the answer I suspect
> > > should be "ask the colorspace property", as mentioned in the
> > > other mail
> > >
> > > * Should we flat out reject color formats (and I suppose also
> > > colorspace prop values) the sink doesn't claim to support?
> > >
> > > If yes, then I think we'll have to forget about adding anything
> > > to i915 MST code. The way the MST stuff works is that if one
> > > stream needs a modeset then all the related streams get modeset
> > > as well. Thus if the user replaces a monitor getting fed with a
> > > YCbCr stream just as another stream is being modeset, then the
> > > entire atomic commit could fail due to the YCbCr stream getting
> > > rejected.
> > >
> > > I think eventually we might have to invent some mechanism where
> > > all the input into the modeset computation is cached somehow,
> > > and said cache updated only on explicit userspace modesets.
> > > Either that or we have to come up with a way to skip some of
> > > the calculations that depend on external factors. Either way
> > > it's going to be a pain.
> > >
> > > OTOH if we don't mind feeding the sink with stuff it can't
> > > understand, then I suppose we might add YCbCr 4:4:4 support
> > > for MST. It shouldn't be any different from RGB apart from
> > > the RGB->YCbCr conversion, which is handled elsewhere. But
> > > YCbCr 4:2:0 is definitely out either way, the MST code has
> > > no support for that currently.
> > >
> >
> >
>
>
>
--
Ville Syrjälä
Intel
On Saturday, 28 March 2026 01:49:04 Central European Standard Time Ville Syrjälä wrote:
> On Fri, Mar 27, 2026 at 01:56:06PM +0100, Nicolas Frattaroli wrote:
> > On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> > > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > > +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
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > > > + * not subsampled)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > > > >
> > > > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > > > should be for each format.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > > > by other properties.
> > > > > > > > > >
> > > > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > > > knowledge, and hopefully none ever will.
> > > > > > > > >
> > > > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > > > >
> > > > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > > > RGB can either be full or limited range depending on the
> > > > > > > > > "Broadcast RGB" property and other related factors.
> > > > > > > >
> > > > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > > > field of its own?
> > > > > > >
> > > > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > > > I think the assumption is limited range everywhere.
> > > > > > >
> > > > > > > But I'm not really concerned about documenting struct members.
> > > > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > > > will want to know what the new property actually does so the
> > > > > > > uapi needs to be documented properly. And down the line some
> > > > > > > new driver might also implement the wrong behaviour if there
> > > > > > > is no clear specification.
> > > > > >
> > > > > > Ack
> > > > > >
> > > > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > > > - YCbCr limited range
> > > > > > > - RGB full range if "Broadcast RGB" property is not present
> > > > > >
> > > > > > Isn't it much more complicated than that for HDMI though? My
> > > > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > > > anything else full range?
> > > > >
> > > > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > > > those would always go hand in hand now.
> > > >
> > > > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > > > think?) but it looks like only vc4 registers the Broadcast RGB property
> > > > and uses the HDMI state helpers.
> > > >
> > > > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > > > drm_default_rgb_quant_range() which seems suspicious?
> > >
> > > If they want just manual full vs. limited then they should
> > > limit the property to not expose the "auto" option at all.
> > >
> > > amdgpu also ties this in with the "colorspace" property, which
> > > originally in i915 only controlled the infoframes/etc. But on
> > > amdgpu it now controls various aspects of output color
> > > transformation. The end result is that the property is a complete
> > > mess with most of the values making no sense. And for whatever
> > > reason everyone involved refused to remove/deprecate the
> > > nonsensical values :/
> > >
> > > Looks like this series should make sure the documentation for
> > > the "colorspace" property is in sync with the new property
> > > as well. Currently now it's giving conflicting information.
> > >
> >
> > I take it the problematic information is in
> >
> > * DOC: standard connector properties
> > *
> > * Colorspace:
> >
> > and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
> > that they "produce RGB content".
> >
> > I think we probably just have to change the statement "The variants
> > BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
> > RGB and YCbCr on its own."
> >
> > The "on its own" here would get turned into "based on the color format
> > property".
> >
> > Speaking of i915, that patch is one of the very few (5) patches in
> > this series still lacking a review (hint hint nudge nudge). I'd like
> > to get some more feedback on the remaining patches before I send out
> > another revision, so that it's hopefully not just docs changes (I
> > know better than to think those patches must be perfect and won't
> > need revision.)
>
> The i915 code around this is already a big mess, and I don't really
> adding to that mess. So I think we'll need to do some refactoring before
> we add anything there. I already started typing something and so far
> it looks fairly straightforward, so I should have something soon.
>
> While doing that several questions came to my mind though:
>
> * More interactions with the colorspace property, but I sent
> a separate mail already about that
>
> * Which conversion matrix to use, and the answer I suspect
> should be "ask the colorspace property", as mentioned in the
> other mail
>
> * Should we flat out reject color formats (and I suppose also
> colorspace prop values) the sink doesn't claim to support?
That is currently the intention, yes. In the common HDMI state
helper, hdmi_try_format_bpc will return false if a format isn't
supported by the sink at a certain bpc, and ultimately, make its
caller return -EINVAL if it's not supported at any bpc.
Userspace asking for something impossible will result in userspace
being told so during atomic check, or at least that's the intention.
> If yes, then I think we'll have to forget about adding anything
> to i915 MST code. The way the MST stuff works is that if one
> stream needs a modeset then all the related streams get modeset
> as well. Thus if the user replaces a monitor getting fed with a
> YCbCr stream just as another stream is being modeset, then the
> entire atomic commit could fail due to the YCbCr stream getting
> rejected.
Yeah, my patch has an MST implementation for i915 and it does "work"
for the simple case where monitors don't have different sets of
supported formats, but I think it's better we make MST just not
have the property. May also drop it from amdgpu as a consequence.
> I think eventually we might have to invent some mechanism where
> all the input into the modeset computation is cached somehow,
> and said cache updated only on explicit userspace modesets.
> Either that or we have to come up with a way to skip some of
> the calculations that depend on external factors. Either way
> it's going to be a pain.
>
> OTOH if we don't mind feeding the sink with stuff it can't
> understand, then I suppose we might add YCbCr 4:4:4 support
> for MST. It shouldn't be any different from RGB apart from
> the RGB->YCbCr conversion, which is handled elsewhere. But
> YCbCr 4:2:0 is definitely out either way, the MST code has
> no support for that currently.
My general approach so far has been that we should never feed
the sink anything it can't handle. This results in some fun edge
cases, e.g. my primary monitor (ASUS XG27AQDMG) does support
YCbCr 4:2:0 on all modes, but since I'm talking to it from an
HDMI 1.4b device, it only exposes the two modes in the EDID it
sends the device as YCbCr 4:2:0 that need it. In that case, the
kernel is stricter than the sink because it takes it by its word.
I think forcing userspace to make safer choices is preferable over
having the monitor lose its picture. If people want to be
adventurous, they can always override the EDID, and thus get away
with such things.
Kind regards,
Nicolas Frattaroli
On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > +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
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > + * not subsampled)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > + * with horizontal subsampling)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > + * with horizontal and vertical subsampling)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > >
> > > > > Seems like this should document what the quantization range
> > > > > should be for each format.
> > > > >
> > > >
> > > > I don't think so? If you want per-component bit depth values,
> > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > enum is more abstract than that, and is there to communicate
> > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > by other properties.
> > > >
> > > > If you mean the factor used for subsampling, then that'd only be
> > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > be added; no digital display protocol standard supports it to my
> > > > knowledge, and hopefully none ever will.
> > >
> > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > >
> > > The i915 behaviour is that YCbCr is always limited range,
> > > RGB can either be full or limited range depending on the
> > > "Broadcast RGB" property and other related factors.
> >
> > So far the HDMI state has both the format and quantization range as
> > different fields. I'm not sure we need to document the range in the
> > format field, maybe only mention it's not part of the format but has a
> > field of its own?
>
> I think we only have it for RGB (on some drivers only?). For YCbCr
> I think the assumption is limited range everywhere.
>
> But I'm not really concerned about documenting struct members.
> What I'm talking about is the *uapi* docs. Surely userspace
> will want to know what the new property actually does so the
> uapi needs to be documented properly. And down the line some
> new driver might also implement the wrong behaviour if there
> is no clear specification.
>
> So I'm thinking (or perhaps hoping) the rule might be something like:
> - YCbCr limited range
> - RGB full range if "Broadcast RGB" property is not present
> - RGB full or limited range based on the "Broadcast RGB" property
> if it's present
>
> I think the "Broadcast RGB" property itself might also be lacking
> proper uapi docs, so that may need to be remedied as well.
Oh, and I think a bunch of infoframe code still needs changes to
set up the quantization range properly for YCbCr. i915 does handle
that part correctly, but eg. hdmi_generate_avi_infoframe() does not.
I didn't spot any changes to that in the series.
--
Ville Syrjälä
Intel
On Wednesday, 25 March 2026 12:03:07 Central European Standard Time Ville Syrjälä wrote:
> On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > +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
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > + * not subsampled)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > + * with horizontal subsampling)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > + * with horizontal and vertical subsampling)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > >
> > > > > Seems like this should document what the quantization range
> > > > > should be for each format.
> > > > >
> > > >
> > > > I don't think so? If you want per-component bit depth values,
> > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > enum is more abstract than that, and is there to communicate
> > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > by other properties.
> > > >
> > > > If you mean the factor used for subsampling, then that'd only be
> > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > be added; no digital display protocol standard supports it to my
> > > > knowledge, and hopefully none ever will.
> > >
> > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > >
> > > The i915 behaviour is that YCbCr is always limited range,
> > > RGB can either be full or limited range depending on the
> > > "Broadcast RGB" property and other related factors.
> >
> > So far the HDMI state has both the format and quantization range as
> > different fields. I'm not sure we need to document the range in the
> > format field, maybe only mention it's not part of the format but has a
> > field of its own?
>
> I think we only have it for RGB (on some drivers only?). For YCbCr
> I think the assumption is limited range everywhere.
>
> But I'm not really concerned about documenting struct members.
> What I'm talking about is the *uapi* docs. Surely userspace
> will want to know what the new property actually does so the
> uapi needs to be documented properly. And down the line some
> new driver might also implement the wrong behaviour if there
> is no clear specification.
>
> So I'm thinking (or perhaps hoping) the rule might be something like:
> - YCbCr limited range
> - RGB full range if "Broadcast RGB" property is not present
> - RGB full or limited range based on the "Broadcast RGB" property
> if it's present
>
> I think the "Broadcast RGB" property itself might also be lacking
> proper uapi docs, so that may need to be remedied as well.
>
>
Alright, so in v12 I'll do the following:
- Add a line to all YCBCR connector formats that specifies they're
limited range as long as Broadcast RGB is limited. Whether it's limited
range when Broadcast RGB is full is purposefully left undefined.
In the future, we can expand this to state they're limited range by
default unless some other property is set. If we're not re-using
Broadcast RGB for that, this will work out fine, because users who
don't know about the eventual new property won't have this behaviour
changed. If we do re-use "Broadcast RGB" for that, then only users
relying on things we explicitly left undefined will get surprise
full range YCBCR.
- Add a line to the RGB connector format that specifies its range
depends on the "Broadcast RGB" property
This is a bit of a mess, because it's entirely reasonable that a
future YCBCR range property would want to default to full range
so that users get the most color out of their monitors. But with
this description of the connector color formats, we can't do that.
If there are alternate suggestions, I'm open for them. We can't
really rename "Broadcast RGB" but if I had a time machine, that'd
be my first choice.
Kind regards,
Nicolas Frattaroli
Hi there, On Thu, 26 Mar 2026 at 12:44, Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote: > On Wednesday, 25 March 2026 12:03:07 Central European Standard Time Ville Syrjälä wrote: > > But I'm not really concerned about documenting struct members. > > What I'm talking about is the *uapi* docs. Surely userspace > > will want to know what the new property actually does so the > > uapi needs to be documented properly. And down the line some > > new driver might also implement the wrong behaviour if there > > is no clear specification. > > > > So I'm thinking (or perhaps hoping) the rule might be something like: > > - YCbCr limited range > > - RGB full range if "Broadcast RGB" property is not present > > - RGB full or limited range based on the "Broadcast RGB" property > > if it's present > > > > I think the "Broadcast RGB" property itself might also be lacking > > proper uapi docs, so that may need to be remedied as well. > > Alright, so in v12 I'll do the following: > > - Add a line to all YCBCR connector formats that specifies they're > limited range as long as Broadcast RGB is limited. Whether it's limited > range when Broadcast RGB is full is purposefully left undefined. > In the future, we can expand this to state they're limited range by > default unless some other property is set. If we're not re-using > Broadcast RGB for that, this will work out fine, because users who > don't know about the eventual new property won't have this behaviour > changed. If we do re-use "Broadcast RGB" for that, then only users > relying on things we explicitly left undefined will get surprise > full range YCBCR. > - Add a line to the RGB connector format that specifies its range > depends on the "Broadcast RGB" property > > This is a bit of a mess, because it's entirely reasonable that a > future YCBCR range property would want to default to full range > so that users get the most color out of their monitors. But with > this description of the connector color formats, we can't do that. > > If there are alternate suggestions, I'm open for them. We can't > really rename "Broadcast RGB" but if I had a time machine, that'd > be my first choice. 'Broadcast RGB' isn't what you want even if it could handle YUV, since it also sets up colour transforms to modify the data ... so we need a separate, orthogonal, property which only affects the HDMI infoframe, rather than applying any transforms. Cheers, Daniel
On Thu, Mar 26, 2026 at 01:44:03PM +0100, Nicolas Frattaroli wrote:
> On Wednesday, 25 March 2026 12:03:07 Central European Standard Time Ville Syrjälä wrote:
> > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > +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
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > + * not subsampled)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > + * with horizontal subsampling)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > >
> > > > > > Seems like this should document what the quantization range
> > > > > > should be for each format.
> > > > > >
> > > > >
> > > > > I don't think so? If you want per-component bit depth values,
> > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > enum is more abstract than that, and is there to communicate
> > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > by other properties.
> > > > >
> > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > be added; no digital display protocol standard supports it to my
> > > > > knowledge, and hopefully none ever will.
> > > >
> > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > >
> > > > The i915 behaviour is that YCbCr is always limited range,
> > > > RGB can either be full or limited range depending on the
> > > > "Broadcast RGB" property and other related factors.
> > >
> > > So far the HDMI state has both the format and quantization range as
> > > different fields. I'm not sure we need to document the range in the
> > > format field, maybe only mention it's not part of the format but has a
> > > field of its own?
> >
> > I think we only have it for RGB (on some drivers only?). For YCbCr
> > I think the assumption is limited range everywhere.
> >
> > But I'm not really concerned about documenting struct members.
> > What I'm talking about is the *uapi* docs. Surely userspace
> > will want to know what the new property actually does so the
> > uapi needs to be documented properly. And down the line some
> > new driver might also implement the wrong behaviour if there
> > is no clear specification.
> >
> > So I'm thinking (or perhaps hoping) the rule might be something like:
> > - YCbCr limited range
> > - RGB full range if "Broadcast RGB" property is not present
> > - RGB full or limited range based on the "Broadcast RGB" property
> > if it's present
> >
> > I think the "Broadcast RGB" property itself might also be lacking
> > proper uapi docs, so that may need to be remedied as well.
> >
> >
>
> Alright, so in v12 I'll do the following:
>
> - Add a line to all YCBCR connector formats that specifies they're
> limited range as long as Broadcast RGB is limited. Whether it's limited
> range when Broadcast RGB is full is purposefully left undefined.
"Broadcast RGB", as the name implies, only affects RGB output.
> In the future, we can expand this to state they're limited range by
> default unless some other property is set. If we're not re-using
> Broadcast RGB for that, this will work out fine, because users who
> don't know about the eventual new property won't have this behaviour
> changed. If we do re-use "Broadcast RGB" for that, then only users
> relying on things we explicitly left undefined will get surprise
> full range YCBCR.
> - Add a line to the RGB connector format that specifies its range
> depends on the "Broadcast RGB" property
>
> This is a bit of a mess, because it's entirely reasonable that a
> future YCBCR range property would want to default to full range
> so that users get the most color out of their monitors. But with
> this description of the connector color formats, we can't do that.
>
> If there are alternate suggestions, I'm open for them. We can't
> really rename "Broadcast RGB" but if I had a time machine, that'd
> be my first choice.
>
> Kind regards,
> Nicolas Frattaroli
>
--
Ville Syrjälä
Intel
On Thursday, 26 March 2026 14:07:15 Central European Standard Time Ville Syrjälä wrote:
> On Thu, Mar 26, 2026 at 01:44:03PM +0100, Nicolas Frattaroli wrote:
> > On Wednesday, 25 March 2026 12:03:07 Central European Standard Time Ville Syrjälä wrote:
> > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > +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
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > + * not subsampled)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > + * with horizontal subsampling)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > >
> > > > > > > Seems like this should document what the quantization range
> > > > > > > should be for each format.
> > > > > > >
> > > > > >
> > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > enum is more abstract than that, and is there to communicate
> > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > by other properties.
> > > > > >
> > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > be added; no digital display protocol standard supports it to my
> > > > > > knowledge, and hopefully none ever will.
> > > > >
> > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > >
> > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > RGB can either be full or limited range depending on the
> > > > > "Broadcast RGB" property and other related factors.
> > > >
> > > > So far the HDMI state has both the format and quantization range as
> > > > different fields. I'm not sure we need to document the range in the
> > > > format field, maybe only mention it's not part of the format but has a
> > > > field of its own?
> > >
> > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > I think the assumption is limited range everywhere.
> > >
> > > But I'm not really concerned about documenting struct members.
> > > What I'm talking about is the *uapi* docs. Surely userspace
> > > will want to know what the new property actually does so the
> > > uapi needs to be documented properly. And down the line some
> > > new driver might also implement the wrong behaviour if there
> > > is no clear specification.
> > >
> > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > - YCbCr limited range
> > > - RGB full range if "Broadcast RGB" property is not present
> > > - RGB full or limited range based on the "Broadcast RGB" property
> > > if it's present
> > >
> > > I think the "Broadcast RGB" property itself might also be lacking
> > > proper uapi docs, so that may need to be remedied as well.
> > >
> > >
> >
> > Alright, so in v12 I'll do the following:
> >
> > - Add a line to all YCBCR connector formats that specifies they're
> > limited range as long as Broadcast RGB is limited. Whether it's limited
> > range when Broadcast RGB is full is purposefully left undefined.
>
> "Broadcast RGB", as the name implies, only affects RGB output.
Alright, I'll scratch the overcomplicated undefined behaviour thing
and just say it's limited range, and in the future, we can extend it
to limited range by default but full range if another new property is
set.
>
> > In the future, we can expand this to state they're limited range by
> > default unless some other property is set. If we're not re-using
> > Broadcast RGB for that, this will work out fine, because users who
> > don't know about the eventual new property won't have this behaviour
> > changed. If we do re-use "Broadcast RGB" for that, then only users
> > relying on things we explicitly left undefined will get surprise
> > full range YCBCR.
> > - Add a line to the RGB connector format that specifies its range
> > depends on the "Broadcast RGB" property
> >
> > This is a bit of a mess, because it's entirely reasonable that a
> > future YCBCR range property would want to default to full range
> > so that users get the most color out of their monitors. But with
> > this description of the connector color formats, we can't do that.
> >
> > If there are alternate suggestions, I'm open for them. We can't
> > really rename "Broadcast RGB" but if I had a time machine, that'd
> > be my first choice.
> >
> > Kind regards,
> > Nicolas Frattaroli
> >
>
>
On Tuesday, 24 March 2026 20:53:35 Central European Standard Time Ville Syrjälä wrote:
> On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > +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
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > + * not subsampled)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > + * with horizontal subsampling)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > + * with horizontal and vertical subsampling)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > >
> > > Seems like this should document what the quantization range
> > > should be for each format.
> > >
> >
> > I don't think so? If you want per-component bit depth values,
> > DRM_FORMAT_* defines would be the appropriate values to use. This
> > enum is more abstract than that, and is there to communicate
> > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > by other properties.
> >
> > If you mean the factor used for subsampling, then that'd only be
> > relevant if YCBCR410 was supported where one chroma plane isn't
> > halved but quartered in resolution. I suspect 4:1:0 will never
> > be added; no digital display protocol standard supports it to my
> > knowledge, and hopefully none ever will.
>
> No, I mean the quantization range (16-235 vs. 0-255 etc).
>
> The i915 behaviour is that YCbCr is always limited range,
> RGB can either be full or limited range depending on the
> "Broadcast RGB" property and other related factors.
>
>
I do agree that this would be useful to be precise about, but I'm
not sure mainline is currently capable of even making a definitive
statement about this because every implementation will do its own
thing probably.
If we do add YCbCr quantization range as a separate property (though
I'd really would've loved it if "Broadcast RGB" was named differently
so it wouldn't be confusing if we overloaded that property's meaning
to also apply to YCbCr) then the resulting docs change for these
enums would be to say that quantization range is a separate property.
I do think making it separate is the best path forward, and I'm willing
to adjust the docs to mention this, but I think implementing YCbCr limited
versus full range in this series as well would drastically widen the scope
again.
Kind regards,
Nicolas Frattaroli
© 2016 - 2026 Red Hat, Inc.