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. 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 >
pgp8G8TlRJbgR.pgp
Description: OpenPGP digital signature
