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.
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.
*/
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?
--- 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
