Hi Russell,
On 8 December 2017 at 12:31, Russell King <rmk+kernel@xxxxxxxxxxxxxxx> wrote:
> Add the defacto-standard "iturbt_709" property to the overlay plane to
> control the YUV to RGB colorspace conversion. This is mutually
> exclusive with the CSC_YUV CRTC property - the last property to be set
> determines the resulting colorspace conversion.
I haven't seen this in other drivers - is it a 'defacto standard'? I
prefer VIlle's choice of an explicit 601/709 enum, since that's more
easily expandable. I do worry about the interaction with the CTM
properties, but I also don't have a good answer as to what that would
look like. I also worry that implementing the 'last-property-set'
semantics might be difficult to implement in an atomic driver.
> struct armada_ovl_plane {
> @@ -252,6 +254,10 @@ armada_ovl_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
> if (!dcrtc->plane) {
> dcrtc->plane = plane;
> armada_ovl_update_attr(&dplane->prop, dcrtc);
> + if (dplane->prop.csc_set) {
> + armada_drm_crtc_set_yuv_colorimetry(dcrtc, dplane->prop.csc);
> + dplane->prop.csc_set = false;
> + }
> }
Just trying to understand this a little better: setting this property
on a plane results in a CRTC change. This is only implemented for the
overlay ('video') plane, but the primary ('graphics') plane also
supports YUV formats. Does this mean that the two planes have to have
the same configuration wrt 601/709 if both are YUV? That could again
get painful to express.
Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
