Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
> On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > >
> > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > >
> > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
> > > > > > > >
> > > > > > > > We want compositors to be able to set the output
> > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > caps reported from the receiver via EDID.
> > > > > > >
> > > > > > > About that... The documentation says that user space has to check the
> > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > >
> > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > Not great at all. Something to remember for the new property.
> > > > > >
> > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > forbid it :/
> > > > >
> > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > uses RGB or YCbCr signalling?
> > > >
> > > > I suppose it could. The modeset would then fail, which is perhaps
> > >
> > > Could? What are they missing?
> >
> > The fact that the new property that also affects the rgb->ycbcr matrix
> > doesn't even exist?
> 
> I think the question was about the current Colorspace property.
> 
> > >
> > > I mean, drivers are already automatically choosing between RGB and YCbCr
> > > signalling based on e.g. available bandwidth. Surely they already will
> > > not attempt to send a signal format to a monitor that does not say it
> > > supports that?
> 
> That's exactly what they do. The drivers don't check the EDID for the
> colorimetry the sink supports and the responsibility is punted off to
> user space.
> 
> >
> > We just signal default/bt.709 colorimetry. There is nothing to
> > check for those IIRC.
> 
> You do support bt.2020, no?

Not for rgb->ycbcr conversion.

> 
> > >
> > > > not a huge issue, except maybe for suspend+resume if we fail in
> > > > the resume path. Although I guess the EDID/etc. should not yet
> > > > be refreshed at that point so if the modeset worked before suspend
> > > > resume should be able to restore it without failures.
> > >
> > > I assumed that if a monitor can be driven, and it supports any BT2020
> > > format, then it always supports the BT2020 format it is being driven
> > > in (RGB vs. YCbCr flavors). Bad assumption?
> >
> > I didn't spot any rule that both must be there. But didn't look
> > too hard either.
> 
> Didn't see anything like that either and I looked a bit harder as well.
> 
> >
> > --
> > Ville Syrjälä
> > Intel
> >

-- 
Ville Syrjälä
Intel