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

[Pekka Paalanen]

On Thu, 16 Mar 2023 12:47:51 +0200
Ville Syrjälä <ville.syrjala at 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 at 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 at 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?

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?

> 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?


Thanks,
pq

> > 
> > So if EDID says only one of them is supported, userspace should be
> > confident that that is the BT2020 mode the driver will match?
> > 
> > 
> > Thanks,
> > pq
> >   
> > >   
> > > >     
> > > > > Signed-off-by: Harry Wentland <harry.wentland at amd.com>
> > > > > Cc: Pekka Paalanen <ppaalanen at gmail.com>
> > > > > Cc: Sebastian Wick <sebastian.wick at redhat.com>
> > > > > Cc: Vitaly.Prosyak at amd.com
> > > > > Cc: Joshua Ashton <joshua at froggi.es>
> > > > > Cc: dri-devel at lists.freedesktop.org
> > > > > Cc: amd-gfx at lists.freedesktop.org
> > > > > Reviewed-By: Joshua Ashton <joshua at froggi.es>
> > > > > ---
> > > > >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++++++++++++++
> > > > >  1 file changed, 15 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > > index f91b2ea13d96..2d883c6dae90 100644
> > > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > > @@ -7184,6 +7184,12 @@ static int amdgpu_dm_connector_get_modes(struct drm_connector *connector)
> > > > >         return amdgpu_dm_connector->num_modes;
> > > > >  }
> > > > >
> > > > > +static const u32 supported_colorspaces =
> > > > > +       BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> > > > > +       BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> > > > > +       BIT(DRM_MODE_COLORIMETRY_BT2020) |
> > > > > +       BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
> > > > > +
> > > > >  void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> > > > >                                      struct amdgpu_dm_connector *aconnector,
> > > > >                                      int connector_type,
> > > > > @@ -7264,6 +7270,15 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> > > > >                                 adev->mode_info.abm_level_property, 0);
> > > > >         }
> > > > >
> > > > > +       if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> > > > > +               if (!drm_mode_create_hdmi_colorspace_property(&aconnector->base, supported_colorspaces))
> > > > > +                       drm_connector_attach_colorspace_property(&aconnector->base);
> > > > > +       } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > > > > +                  connector_type == DRM_MODE_CONNECTOR_eDP) {
> > > > > +               if (!drm_mode_create_dp_colorspace_property(&aconnector->base, supported_colorspaces))
> > > > > +                       drm_connector_attach_colorspace_property(&aconnector->base);
> > > > > +       }
> > > > > +
> > > > >         if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > > > >             connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > > > >             connector_type == DRM_MODE_CONNECTOR_eDP) {
> > > > > --
> > > > > 2.39.2
> > > > >    
> > >   
> >   
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20230316/a3833b6b/attachment-0001.sig>