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
signature.asc
Description: PGP signature
