linux-kernel - Re: [PATCH 07/11] drm/colorop: Introduce HLG EOTF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45b44706a86046b795b3a29d3987b7764455b21d.camel@collabora.com>
Date: Fri, 06 Feb 2026 09:02:31 -0500
From: Nícolas "F. R. A. Prado" <nfraprado@...labora.com>
To: Pekka Paalanen <pekka.paalanen@...labora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard	
 <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie
	 <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Chun-Kuang Hu	
 <chunkuang.hu@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>, Matthias
 Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno	
 <angelogioacchino.delregno@...labora.com>, dri-devel@...ts.freedesktop.org,
 	linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org, 
	linux-arm-kernel@...ts.infradead.org, daniels@...labora.com, 
	ariel.dalessandro@...labora.com, kernel@...labora.com
Subject: Re: [PATCH 07/11] drm/colorop: Introduce HLG EOTF

On Fri, 2026-02-06 at 10:51 +0200, Pekka Paalanen wrote:
> On Tue, 23 Dec 2025 16:44:48 -0300
> Nícolas F. R. A. Prado <nfraprado@...labora.com> wrote:
> 
> > Introduce definition of a hybrid log-gamma electro-optical transfer
> > function for 1D Curve colorops.
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@...labora.com>
> > ---
> >  drivers/gpu/drm/drm_colorop.c |  1 +
> >  include/drm/drm_colorop.h     | 10 ++++++++++
> >  2 files changed, 11 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_colorop.c
> > b/drivers/gpu/drm/drm_colorop.c
> > index fafe45b93ff8..a19e03fb9c7c 100644
> > --- a/drivers/gpu/drm/drm_colorop.c
> > +++ b/drivers/gpu/drm/drm_colorop.c
> > @@ -79,6 +79,7 @@ static const char * const
> > colorop_curve_1d_type_names[] = {
> >  	[DRM_COLOROP_1D_CURVE_BT2020_OETF] = "BT.2020 OETF",
> >  	[DRM_COLOROP_1D_CURVE_GAMMA22] = "Gamma 2.2",
> >  	[DRM_COLOROP_1D_CURVE_GAMMA22_INV] = "Gamma 2.2 Inverse",
> > +	[DRM_COLOROP_1D_CURVE_HLG_EOTF] = "HLG",
> >  };
> >  
> >  static const struct drm_prop_enum_list
> > drm_colorop_lut1d_interpolation_list[] = {
> > diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> > index ee6454b08b2d..8ec98521607d 100644
> > --- a/include/drm/drm_colorop.h
> > +++ b/include/drm/drm_colorop.h
> > @@ -126,6 +126,16 @@ enum drm_colorop_curve_1d_type {
> >  	 * The inverse of &DRM_COLOROP_1D_CURVE_GAMMA22
> >  	 */
> >  	DRM_COLOROP_1D_CURVE_GAMMA22_INV,
> > +
> > +	/**
> > +	 * @DRM_COLOROP_1D_CURVE_HLG_EOTF:
> > +	 *
> > +	 * enum string "HLG"
> > +	 *
> > +	 * Hybrid log-gamma transfer function.
> > +	 */
> > +	DRM_COLOROP_1D_CURVE_HLG_EOTF,
> > +
> 
> Hi,
> 
> if you read ITU-R BT.2100[1], you will see that the HLG EOTF has
> three
> parameters: the system gamma, the display nominal peak luminance, and
> the display black luminance. You cannot define a HLG EOTF or its
> inverse without these parameters. One might assume to derive the
> system
> gamma from the peak luminance, but I would like to leave that as a
> free
> parameter if possible, because I'm not convinced the formulas for it
> are
> universally applicable.
> 
> The HLG OETF on the other hand is a fixed function. Did you mean that
> instead?

Thank you for the insights! But as it's obvious by now I don't have
enough information to answer that. Hopefully someone from MediaTek
could clarify what is the precise function implemented in hardware.

I didn't know about this difference between the HLG EOTF and OETF, but
what made me guess it would be the EOTF is that this curve is available
at the GAMMA block, which is right before blending the planes (the
pipeline topology I reverse-engineered from testing is on the cover-
letter), which I believe is usually done in the optical domain. But I
suppose one option would be that this curve really is the Inverse HLG
OETF, which wouldn't require additional parameters and also brings the
content to the optical domain.

-- 
Thanks,

Nícolas