On 2025/09/12, Maxime Ripard wrote: > On Thu, Sep 11, 2025 at 04:07:35PM +0300, Marius Vlad wrote: > > This would please the compiler to have a enum transformation from one to > > another even though the values are the same. It should also make things > > obvious that we use different enums. > > > > Signed-off-by: Marius Vlad <[email protected]> > > --- > > .../gpu/drm/display/drm_hdmi_state_helper.c | 4 +++- > > drivers/gpu/drm/drm_connector.c | 18 ++++++++++++++++++ > > include/drm/drm_connector.h | 3 +++ > > 3 files changed, 24 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c > > b/drivers/gpu/drm/display/drm_hdmi_state_helper.c > > index f9aa922d25d3..dc2f32651cb9 100644 > > --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c > > +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c > > @@ -653,9 +653,11 @@ hdmi_compute_config(const struct drm_connector > > *connector, > > conn_state->max_bpc, > > 8, connector->max_bpc); > > int ret; > > + enum hdmi_colorspace hdmi_colorspace = > > + color_format_to_hdmi_colorspace(conn_state->color_format); > > > > ret = hdmi_compute_format_bpc(connector, conn_state, mode, max_bpc, > > - HDMI_COLORSPACE_RGB); > > + hdmi_colorspace); > > if (ret) { > > if (connector->ycbcr_420_allowed) { > > ret = hdmi_compute_format_bpc(connector, conn_state, > > Does it really make sense to have the fallback to YUV420 here? I would > expect to get rid of it, or only use that for "auto".
I think we should keep both RGB and YUV420 fallbacks, obviously making them conditional on the requested color format to avoid redundant checks. E.g. if user-space has a preference on YUV444 which ends up not being supported, switch to RGB, unless we're on a YUV420-only mode. This would also require a reverse conversion from the resulting HDMI colorspace stored in conn_state->hdmi.output_format and update conn_state->color_format accordingly, so that all involved parties will employ the actual color format rather than the user-preferred one.
