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