On Fri, May 26, 2023 at 3:16 PM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > > On Thu, 25 May 2023 15:17:56 -0400 > Harry Wentland <harry.wentland@xxxxxxx> wrote: > > > This patchset is based on Joshua's previous patchset [1], as well > > as my previous patchset [2]. > > > > It is > > - enabling support for the colorspace property in amdgpu, as well as > > - allowing drivers to specify the supported set of colorspaces, and > > > > Colorspace, Infoframes, and YCbCr matrix > > --------------------------------------- > > > > Even though the initial intent of the colorspace property was to set the > > colorspace field in the respective HDMI AVI and DP SDP infoframes that > > is not sufficient in all scenarios. For DP the colorspace information > > also affects the MSA (main stream attribute) packet. For YUV output the > > colorspace affects the RGB-to-YCbCr conversion matrix. The colorspace > > field of the infopackets also depends on the encoding used, which is > > something that is decided by the driver and not known to userspace. > > Hi Harry, > > the "deprecation" of BT2020 RGB vs. YCC is now dropped completely. > Should there still be a patch that adds some UAPI documentation only, > saying that drivers are free to swap e.g. between BT2020 RGB and YCC > based which encoding they actually chose? Yes please! > Even if just BT2020 variant specifically. > > I have nothing against with this series now. > > > Thanks, > pq > > > > > For these reasons a driver will need to be able to select the supported > > colorspaces at property creation. > > > > Note: There seems to be an understanding that the colorspace property > > should ONLY modify the infoframe. While this is current behavior and > > sufficient in some cases it is nowhere specified that this should be the > > only use of this property. As outlined above this limitation is not > > going to work in all cases. > > > > This patchset does not affect current behavior for the drivers that > > implement this property: i915 and vc4. > > > > In the future we might want to give userspace control over the encoding > > format on the wire, in particular to avoid use of YUV420 when image > > fidelity is important. This work would likely go hand in hand with a > > min_bpc property and wouldn't conflict with the work done in this > > patchset. I would expect this future work to tag along with a drm_crtc > > or drm_connector's Color Pipeline, similar to the one propsed for > > drm_plane [3]. > > > > Colorspace on crtc or connector? > > -------------------------------- > > > > There have been suggestions of programming 'colorspace' on the drm_crtc > > but I don't think the crtc is the right place for this property. The > > drm_plane and drm_crtc will be used to offload color processing that > > would normally be done via the GFX or other pipelines. The drm_connector > > controls the signalling with the display and ensures the wire format is > > appropriate for the encoding by programming the RGB-to-YCbCr matrix. > > > > [1] https://patchwork.freedesktop.org/series/113632/ > > [2] https://patchwork.freedesktop.org/series/111865/ > > [3] https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html
