On Mon, 22 Sep 2025 21:16:45 -0600 Alex Hung <alex.h...@amd.com> wrote:
> On 9/18/25 02:40, Pekka Paalanen wrote: > > On Tue, 16 Sep 2025 17:01:07 -0600 > > Alex Hung <alex.h...@amd.com> wrote: > > > >> On 8/26/25 03:03, Pekka Paalanen wrote: > >>> On Thu, 21 Aug 2025 11:54:32 -0600 > >>> Alex Hung <alex.h...@amd.com> wrote: > >>> > >>>> On 8/21/25 06:23, Xaver Hugl wrote: > >>>>>> We user space folks have been convinced at this point that the sRGB > >>>>>> EOTF > >>>>>> is actually gamma 2.2, and not the piece-wise function. Now, if the > >>>>>> hardware is actually the piece-wise, then that's what should be > >>>>>> exposed, > >>>>>> but I'm a bit unsure if we should do that under the name sRGB EOTF. > >>>>> Maybe simply rename the enum string to "sRGB piece-wise EOTF"? In > >>>>> hindsight, the naming of "srgb" in the Wayland protocol caused a lot > >>>>> of confusion, it's better to be explicit about it where possible. > >>>> > >>>> I will leave this to Harry to comment. He is taking a few days off so I > >>>> will check with him later. > >>>> > >>> > >>> "sRGB inverse OETF"? > >>> > >>> Strictly speaking "sRGB piece-wise EOTF" is not a thing AFAIU. > >>> > >>> > >>> Thanks, > >>> pq > >> > >> If an extension in future after this proposal is merged, can it be GAMMA > >> 2.2 to be [DRM_COLOROP_1D_CURVE_GAMMA22] = "GAMMA 2.2" so it won't > >> conflict with current name? > >> > >> Meanwhile, do we agree to change "sRGB EOTF" as "sRGB Inverse OETF" as > >> the following? or do we still want to add "piece-wise"? > > > > Hi Alex, > > > > since my previous comment, things have muddied further again. FWIW, we > > intend to remove the use of the name "srgb" transfer function > > completely from the Wayland protocol as confusing: > > > > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/442 > > > > I would recommend the KMS UAPI to similarly avoid the term. I would > > recommend "gamma 2.2" or even "power 2.2" and "compound power 2.4" or > > such. These names would hopefully not trigger intuition and make people > > look at the definition harder. Or any other name you can come up with. > > > > I agree that "piece-wise sRGB EOTF" would be intuitively clear, but it > > may provoke people debating what does IEC 61966-2-1 actually define. > > We've had these kind of discussions for Wayland already, and it was > > suggested that it is better to define the actual mathematical function > > in our specification that to leave it for interpretation from standards. > > > > For KMS, this should be even easier than for Wayland, because the > > hardware implements a specific mathematical function regardless of > > where it might have originated or what it is being used for. > > > > Do you mean the following changes? Userspace use Gamma 2.2, and display > driver can decide to use either sRGB piece-wise EOTF or Gamma 2.2 itself. Sorry, the driver cannot choose. The UAPI needs to define the curves explicitly, and the drivers need to implement those curves exactly(*) or not at all. What I propose is, let's not use "sRGB" in any of the names for the curves, because that name triggers different assumptions in different people. (*) "Exactly" is a little vague here. I assume some error tolerance needs to be allowed, e.g 1 bit on the electrical value. The maximum difference between the two-piece and power-2.2 curves is several code points for 8-bit electrical quantization, and that's too much error. > diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c > index e1b2b446faf2..3a6c64285d9c 100644 > --- a/drivers/gpu/drm/drm_colorop.c > +++ b/drivers/gpu/drm/drm_colorop.c > @@ -71,7 +71,7 @@ static const struct drm_prop_enum_list > drm_colorop_type_enum_list[] = { > }; > > static const char * const colorop_curve_1d_type_names[] = { > - [DRM_COLOROP_1D_CURVE_SRGB_EOTF] = "sRGB EOTF", > + [DRM_COLOROP_1D_CURVE_SRGB_EOTF] = "Gamma 2.2", > [DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF] = "sRGB Inverse EOTF", > [DRM_COLOROP_1D_CURVE_PQ_125_EOTF] = "PQ 125 EOTF", > [DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF] = "PQ 125 Inverse EOTF", > diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h > index 3e70f66940e0..e39379f1a61c 100644 > --- a/include/drm/drm_colorop.h > +++ b/include/drm/drm_colorop.h > @@ -48,7 +48,8 @@ enum drm_colorop_curve_1d_type { > * sRGB piece-wise electro-optical transfer function. Transfer > * characteristics as defined by IEC 61966-2-1 sRGB. Equivalent > * to H.273 TransferCharacteristics code point 13 with > - * MatrixCoefficients set to 0. > + * MatrixCoefficients set to 0. This can also be approximated as > + * Gamma 2.2. The problem is that "H.273 TransferCharacteristics code point 13" a.k.a the sRGB curve means different things for different people (two-piece vs. power-2.2). The difference is minor but visible, and therefore I would not make two-piece and power-2.2 equivalent nor have one approximated by the other. They both need their own entries in the enum. Let's leave any decision about whether substituting one for the other is ok to the userspace. > */ > DRM_COLOROP_1D_CURVE_SRGB_EOTF, > > > It is also possible to add GAMMA 2.2 in addition to sRGB piece-wise > EOTF. But if I understand correctly, DRM_COLOROP_1D_CURVE_SRGB_EOTF may > not be used at all, right? If hardware implements the two-piece curve, then there is reason to expose it, especially when it does not implement power-2.2. Userspace can choose to use it as an approximation when that is appropriate. Thanks, pq > --- a/drivers/gpu/drm/drm_colorop.c > +++ b/drivers/gpu/drm/drm_colorop.c > @@ -77,6 +77,7 @@ static const char * const > colorop_curve_1d_type_names[] = { > [DRM_COLOROP_1D_CURVE_SRGB_EOTF] = "sRGB EOTF", > [DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF] = "PQ 125 Inverse EOTF", > [DRM_COLOROP_1D_CURVE_BT2020_INV_OETF] = "BT.2020 Inverse OETF", > [DRM_COLOROP_1D_CURVE_BT2020_OETF] = "BT.2020 OETF", > + [DRM_COLOROP_1D_CURVE_GAMMA22] = "Gamma 2.2", > }; > > Does anyone have comments or concerns if we use the first option? > > Alex H. > > > > > Thanks, > > pq > > > >> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c > >> index 1551b86471ce..90a216c0b6ac 100644 > >> --- a/drivers/gpu/drm/drm_colorop.c > >> +++ b/drivers/gpu/drm/drm_colorop.c > >> @@ -71,7 +71,7 @@ static const struct drm_prop_enum_list > >> drm_colorop_type_enum_list[] = { > >> }; > >> > >> static const char * const colorop_curve_1d_type_names[] = { > >> - [DRM_COLOROP_1D_CURVE_SRGB_EOTF] = "sRGB EOTF", > >> + [DRM_COLOROP_1D_CURVE_SRGB_EOTF] = "sRGB Inverse OETF", > >> [DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF] = "sRGB Inverse EOTF", > >> [DRM_COLOROP_1D_CURVE_PQ_125_EOTF] = "PQ 125 EOTF", > >> [DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF] = "PQ 125 Inverse EOTF", > >> diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h > >> index e4250b7d8de8..ce85c52c60c8 100644 > >> --- a/include/drm/drm_colorop.h > >> +++ b/include/drm/drm_colorop.h > >> @@ -43,7 +43,7 @@ enum drm_colorop_curve_1d_type { > >> /** > >> * @DRM_COLOROP_1D_CURVE_SRGB_EOTF: > >> * > >> - * enum string "sRGB EOTF" > >> + * enum string "sRGB Inverse OETF" > >> * > >> * sRGB piece-wise electro-optical transfer function. Transfer > >> * characteristics as defined by IEC 61966-2-1 sRGB. Equivalent > >> > > >
pgpNliLScDhAc.pgp
Description: OpenPGP digital signature
