On Fri, Sep 26, 2025 at 05:50:43PM +0300, Cristian Ciocaltea wrote:
> 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.

I think some other part of that thread settled on if userspace
explicitly asks for YUV444 and it can't work on the
encoder/bridge/connector/monitor chain, the commit should be rejected,
and it's up to userspace to pick a reasonable fallback.

We've been asked something the kernel can't do, we should report it as
such and not fallback to something transparent to userspace.

For auto though, we should definitely keep the fallback from RGB to
YUV420.

Maxime

Attachment: signature.asc
Description: PGP signature

Reply via email to