SENDING AGAIN because it was sent with HTML formatting, which screwed up the email. Hi! This is my first patch ever to DRM/amdgpu (technically I didn't write the patch, I just kept rebasing it over 4 years, and did lots of testing). I'm following the advise from: https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_2628536 Why this patch? Because it fix a practical problem with certain monitors that auto-select ycbcr444 when they should be set to "rgb" (this issue also happens on Windows) when plugging an HDMI monitor to a DisplayPort via passive adapter. IMPORTANT remarks about the public API: 1. This API adds "pixel encoding" which has options "auto" (Default), "rgb", "ycbcr444", and "ycbcr420" 2. Intel has "RGB Broadcast". Its options are "Full" and "Limited 16:235". There is a lot of overlap here. On Windows AMD Control Panel offers the option "Pixel Encoding" and its options are: - RGB (full) - RGB (limited) - ycbcr444 - ycbcr420 - ycbcr422 Which means that it may be worth reserving more keywords for this patch. I don't know why ycbcr444/ycbcr420 do not offer full/limited variants on Windows, but I suspect it's because the driver can automatically tell whether to use Full vs Limited for ycbcr variants.. 3. amdgpu already has "Colorspace" option. However this is a different (although related) option. But there is quite the overlap: - Full/Limited options are sometimes included as part of the colorspace, such is the case of COLOR_SPACE_2020_RGB_FULLRANGE vs COLOR_SPACE_2020_RGB_LIMITEDRANGE, but there is no "LIMITED"/"FULL" variants for COLOR_SPACE_2020_YCBCR. Yet there are for YCBCR601 and YCBCR709. This may be a spec thing (I don’t know). - AFAIK amdgpu’s Limited/Full variants are not controllable from the public user-space API. - Certain options in "Colorspace" only makes sense in specific pixel encoding. For example the option "opRGB" currently glitches when amdgpu is using ycbcr encoding (you can tell the monitor is interpreting the RGB signal as YUV, thus white becomes purple and black becomes green). - The kernel has DRM_MODE_COLORIMETRY_BT2020_RGB and DRM_MODE_COLORIMETRY_BT2020_YCC. AMDGPU kernel currently forces COLOR_SPACE_2020_RGB_FULLRANGE or COLOR_SPACE_2020_YCBCR based on the current pixel encoding (e.g. if using RGB encodings and colorspace == DRM_MODE_COLORIMETRY_BT2020_YCC, it will be changed for COLOR_SPACE_2020_RGB_FULLRANGE with currently no choice for Limited range). - amdgpu seems to be able to automatically distinguish between Full and Limited for ycbcr formats via the presence of flags.Y_ONLY bit. There is no such auto-detection for RGB. The way I see it, there are 3 configurations that can be arranged together: - Pixel Encoding (RGB vs ycbcr444 vs ycbcr420). - Colorspace (YCBCR709 vs BT.2020 etc). - Full vs Limited. However not all options are compatible with everything. I suspect doing the same as what AMD does on Windows (offer RGB/Full + RGB/Limited + all the ycbcr variants for "pixel encoding") is the best choice (and leave the "Colorspace" option as is, for very advanced manipulation). 4. Xaver Hugl expressed his concerns with the current patch that having an option called "auto" with no way of querying what is the current auto-selected encoding is sub-optimal. Cheers Matias
