Re: [V7 29/45] drm/colorop: Add PQ 125 EOTF and its inverse

On 2025-01-15 03:00, Simon Ser wrote: > Is this 125 magic number something we can expect other hardware to > implement as well? > It's based on MS's CCCS interpretation of 80 nits as 1.0f [1]. Based on this definition one needs to use 125.0f to represent 10,000 nits, the maximum value PQ can r

Re: [V7 29/45] drm/colorop: Add PQ 125 EOTF and its inverse

On 2025-01-17 04:04, Pekka Paalanen wrote: > On Thu, 19 Dec 2024 21:33:35 -0700 > Alex Hung wrote: > >> From: Harry Wentland >> >> The PQ function defines a mapping of code values to nits (cd/m^2). >> The max code value maps to 10,000 nits. >> >> Windows DWM's canonical composition color spac

Re: [V7 31/45] drm/colorop: add BT2020/BT709 OETF and Inverse OETF

On 2025-01-15 03:04, Simon Ser wrote: >> The BT.709 and BT.2020 OETFs are the same, the only difference >> being that the BT.2020 variant is defined with more precision >> for 10 and 12-bit per color encodings. > > Just to make sure, the spec defines this precision, correct? It's > not an AMD-s

Re: [V7 31/45] drm/colorop: add BT2020/BT709 OETF and Inverse OETF

On 2025-01-17 04:06, Pekka Paalanen wrote: > On Thu, 16 Jan 2025 10:56:22 +0200 > Pekka Paalanen wrote: > >> On Thu, 19 Dec 2024 21:33:37 -0700 >> Alex Hung wrote: >> >>> From: Harry Wentland >>> >>> The BT.709 and BT.2020 OETFs are the same, the only difference >>> being that the BT.2020 va

Re: [V7 43/45] drm/amd/display: Add AMD color pipeline doc

On 2025-01-17 04:19, Pekka Paalanen wrote: > On Thu, 19 Dec 2024 21:33:49 -0700 > Alex Hung wrote: > >> From: Harry Wentland >> >> Add kernel doc for AMD color pipeline. >> >> Signed-off-by: Alex Hung >> Signed-off-by: Harry Wentland >> --- >> .../amd/display/amdgpu_dm/amdgpu_dm_color.c

Re: [V7 23/45] drm/amd/display: Ignore deprecated props when plane_color_pipeline set

On Wednesday, January 22nd, 2025 at 22:05, Harry Wentland wrote: > On 2025-01-15 02:56, Simon Ser wrote: > > > Is this "ignore" something we could do at the core DRM level, instead > > of doing it in all drivers? e.g. by silently ignoring user-space requests > > to set the property? > > I thin

Re: [V7 29/45] drm/colorop: Add PQ 125 EOTF and its inverse

On Thursday, January 23rd, 2025 at 21:06, Harry Wentland wrote: > On 2025-01-15 03:00, Simon Ser wrote: > > > Is this 125 magic number something we can expect other hardware to > > implement as well? > > It's based on MS's CCCS interpretation of 80 nits as 1.0f [1]. Based on > this definition