[PATCH 05/23] drm/amd/display: Fix color encoding mismatch

[Maxime Ripard]

Hi Harry,

On Thu, Feb 10, 2022 at 09:38:24AM -0500, Harry Wentland wrote:
> On 2022-02-10 03:42, Maxime Ripard wrote:
> > On Mon, Feb 07, 2022 at 01:59:38PM -0500, Harry Wentland wrote:
> >> On 2022-02-07 13:57, Harry Wentland wrote:
> >>> On 2022-02-07 11:34, Maxime Ripard wrote:
> >>>> The amdgpu KMS driver calls drm_plane_create_color_properties() with a
> >>>> default encoding set to BT709.
> >>>>
> >>>> However, the core will ignore it and the driver doesn't force it in its
> >>>> plane state reset hook, so the initial value will be 0, which represents
> >>>> BT601.
> >>>>
> >>>
> >>> Isn't this a core issue? Should __drm_atomic_helper_plane_state_reset
> >>> reset all plane_state members to their properties' default values?
> >>>
> >>
> >> Ah, looks like that's exactly what you do in the later patches, which is
> >> perfect. With that, I don't think you'll need this patch anymore.
> > 
> > Ok, I'll squash it into the patch that removes the reset code.
> > 
> 
> I don't think that's right. I think we can just drop this patch.
> The amdgpu display driver is not doing BT601 by default.

My understanding from the code currently in tree is that:

1) amdgpu_dm_plane_init() will call drm_plane_create_color_properties()
   with an initial value set to BT709.

2) dm_drm_plane_reset() will use kzalloc and then just rely on
   __drm_atomic_helper_plane_reset(), which will not set the color encoding
   at all. It's thus 0 in the initial state.

3) the drm_color_encoding enum will have BT601 associated to 0

So it does look like the default for amdgpu at the moment is BT601?

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20220217/0b7dd724/attachment.sig>