;
dan...@ffwll.ch; quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
quic_abhin...@quicinc.com; mar...@marcan.st; liviu.du...@arm.com;
sashamcint...@google.com; louis.chau...@bootlin.com; arthurgri...@riseup.net
Subject: RE: [PATCH V10 33/46] drm: Add Enhanced LUT precision structure
.@system76.com;
> dan...@ffwll.ch; quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; mar...@marcan.st; liviu.du...@arm.com;
> sashamcint...@google.com; louis.chau...@bootlin.com; arthurgri...@riseup.net
> Subject: RE: [PATCH V10 33/46] drm: Add Enhanced LUT p
..@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; Borah, Chaitanya
> Kumar ; louis.chau...@bootlin.com;
> arthurgri...@riseup.net
> Subject: Re: [PATCH V10 33/46] drm: Add Enhanced
On 7/8/25 11:10, Simon Ser wrote:
On Tuesday, June 17th, 2025 at 06:26, Alex Hung wrote:
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 651bdf48b766..21bd96f437e0 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -872,6 +872,16 @@ st
.com; dan...@ffwll.ch; Shankar, Uma
; quic_nas...@quicinc.com;
quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; mar...@marcan.st;
liviu.du...@arm.com; sashamcint...@google.com; Borah, Chaitanya
Kumar ; louis.chau...@bootlin.com;
arthurgri...@riseup.net
Subject: [PATCH V10 33/46] drm: Add Enhanced
On Tuesday, June 17th, 2025 at 06:27, Alex Hung wrote:
> - 1D LUT is no longer immutable (Xaver Hugl)
I think we should keep it immutable for now, and we can make it mutable
in the future when we want to extend the uAPI to make it switchable by
user-space.
ble_color_mgmt(&acrtc->base, is_dcn ? MAX_COLOR_LUT_ENTRIES
: 0,
+ if (plane->color_pipeline_property)
+ has_degamma = false;
+ else
+ has_degamma = dm->adev->dm.dc->caps.color.dpp.dcn_arch;
Just a reminder to take into account this patch (if applie
}
+ if (adev->dm.dc->caps.color.dpp.hw_3d_lut) {
No I think it will not work as expected for movable 3D LUT, since
movable 3D LUT is a MPC capability.
I have actually sent a patch in the past to clarify this on DCN401. So,
this check doesn't cover this driver anymore, for ex
On 17/06/2025 00:17, Alex Hung wrote:
Expose one 1D curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
the sRGB transform when the colorop is not in bypass.
With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf
The co
m76.com; dan...@ffwll.ch; Shankar, Uma
> ; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; Borah, Chaitanya
> Kumar ; louis.chau...@bootlin.com;
> arthurgri...@riseup.net
> Subject
On Tuesday, June 17th, 2025 at 06:26, Alex Hung wrote:
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 651bdf48b766..21bd96f437e0 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -872,6 +872,16 @@ struct drm_color_lut {
> _
fig_test.o vkms_color_test.o
I believe you might need to rebase this patch on top of drm-misc-next
due to 60ba94338047 ("drm/vkms: Compile all tests with
CONFIG_DRM_VKMS_KUNIT_TEST").
diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_test.c
b/drivers/gpu/drm/vkms/tests/vkms_color_test.c
new fi
Hi Alex,
On 17/06/25 01:17, Alex Hung wrote:
From: Harry Wentland
While working on the CTM implementation of VKMS I had to ascertain
myself of a few assumptions. One of those is whether drm_fixed.h
treats its numbers using signed-magnitude or twos-complement. It is
twos-complement.
In order t
Hi Alex,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.16-rc2]
[cannot apply to drm-exynos/exynos-drm-next drm/drm-next drm-misc/drm-misc-next
next-20250618]
[If your patch is applied to the wrong git tree, kindly drop
-tip next-20250617]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Ale
roggi.es;
> > mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> > victo...@system76.com; dan...@ffwll.ch; Shankar, Uma
> > ; quic_nas...@quicinc.com;
> > quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; mar...@marcan.st;
> > liviu.du...@arm.com; sashamcint...
On 2025-06-17 07:04, Maíra Canal wrote:
> Hi Alex,
>
> On 17/06/25 01:17, Alex Hung wrote:
>> From: Harry Wentland
>>
>> While working on the CTM implementation of VKMS I had to ascertain
>> myself of a few assumptions. One of those is whether drm_fixed.h
>> treats its numbers using signed-magnit
y Wentland
Reviewed-by: Daniel Stone
Reviewed-by: Melissa Wen
---
v8:
- Remove null check "colorop->next_property" in drm_colorop_set_next_property
v5:
- move next comment here from Add 3x4 CTM patch (Sebastian)
- Add kernel doc
v4:
- Allow setting of NEXT property to NULL (Cha
From: Harry Wentland
Certain operations require us to preserve values below 0.0 and
above 1.0 (0x0 and 0x respectively in 16 bpc unorm). One
such operation is a BT709 encoding operation followed by its
decoding operation, or the reverse.
We'll use s32 values as intermediate in and outputs of
From: Harry Wentland
When the plane_color_pipeline bit is set we should ignore
deprecated properties, such as COLOR_RANGE and COLOR_ENCODING.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Reviewed-by: Daniel Stone
Reviewed-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/a
, Uma
> ; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com;
> louis.chau...@bootlin.com; Daniel Stone
> Subject: Re: [PATCH V9 16/43] drm/colorop: Add 3x4 CTM type
>
> On Mon, 16 Jun
Swap the order of matrix and multiplier as designed in hardware.
Signed-off-by: Alex Hung
Reviewed-by: Daniel Stone
Reviewed-by: Melissa Wen
---
V9:
- Update function names by _plane_ (Chaitanya Kumar Borah)
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 12 ++--
.../drm/amd/
From: Harry Wentland
We want to make sure userspace is aware of the 1D LUT
interpolation. While linear interpolation is common it
might not be supported on all HW. Give driver implementers
a way to specify their interpolation.
Reviewed-by: Simon Ser
Signed-off-by: Alex Hung
Signed-off-by: Harr
From: Harry Wentland
Not all HW will be able to do bypass on all color
operations. Introduce an 32 bits 'flags' for all colorop
init functions and DRM_COLOROP_FLAG_ALLOW_BYPASS for creating
the BYPASS property when it's true.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Reviewed-by:
Check dpp.hw_3d_lut before creating shaper tf/lut and 3dlut colorops in
colorpipeline and handling these colorops.
Signed-off-by: Alex Hung
---
V10:
- Check dpp.hw_3d_lut before creating shaper tf/lut and 3dlut colorops
(Melissa Wen)
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 47 -
The functions are to clean up color pipeline when a device driver
fails to create its color pipeline.
Signed-off-by: Alex Hung
Reviewed-by: Daniel Stone
Reviewed-by: Simon Ser
Reviewed-by: Melissa Wen
---
v9:
- Move from from latest commit to here, and drm_colorop_pipeline_destroy
is calle
From: Harry Wentland
A whole slew of tests for CTM handling that greatly helped in
debugging the CTM code. The extent of tests might seem a bit
silly but they're fast and might someday help save someone
else's day when debugging this.
Reviewed-by: Louis Chauvet
Signed-off-by: Alex Hung
Signed-
The degamma is to be handled by Color pipeline API.
Signed-off-by: Alex Hung
---
V10:
- Disable CRTC degamma when color pipeline is enabled (Melissa Wen)
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drive
From: Harry Wentland
Add kernel doc for AMD color pipeline.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Reviewed-by: Daniel Stone
Reviewed-by: Melissa Wen
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 122 +++---
1 file changed, 102 insertions(+), 20 deletions(-
It is to be used to enable HDR by allowing userpace to create and pass
3D LUTs to kernel and hardware.
new drm_colorop_type: DRM_COLOROP_3D_LUT.
Reviewed-by: Simon Ser
Signed-off-by: Alex Hung
Reviewed-by: Daniel Stone
Reviewed-by: Melissa Wen
---
V10:
- Add missing set lut3d_interpolation i
This adds support for a 3D LUT.
The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. Multiplier
3. 3x4 CTM
4. 1D curve colorop
5. 1D LUT
6. 3D LUT
7. 1D curve colorop
8. 1D LUT
Signed-off-by: Alex Hung
Reviewed-by: Daniel Stone
---
V10:
- Support 32BIT RGB in 3D LU
This adds support for a multiplier. This multiplier is
programmed via the HDR Multiplier in DCN.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-multiply_125
kms_colorop --run plane-XR30-XR30-multiply_inv_125
The color pipeline now consists of the following coloro
This introduces a new drm_colorop_type: DRM_COLOROP_MULTIPLIER.
It's a simple multiplier to all pixel values. The value is
specified via a S31.32 fixed point provided via the
"MULTIPLIER" property.
Reviewed-by: Simon Ser
Signed-off-by: Alex Hung
Reviewed-by: Daniel Stone
Reviewed-by: Melissa W
This adds support for a 3x4 color transformation matrix.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-ctm_3x4_50_desat
kms_colorop --run plane-XR30-XR30-ctm_3x4_overdrive
kms_colorop --run plane-XR30-XR30-ctm_3x4_oversaturate
kms_colorop --run plane-XR30-XR30-ct
This patch adds colorops for custom 1D LUTs in the SHAPER and
BLND HW blocks.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut-srgb_eotf_lut
The color pipeline now consists of the following
We've previously introduced DRM_COLOROP_1D_CURVE for
pre-defined 1D curves. But we also have HW that supports
custom curves and userspace needs the ability to pass
custom curves, aka LUTs.
This patch introduces a new colorop type, called
DRM_COLOROP_1D_LUT that provides a SIZE property whi
From: Uma Shankar
Existing LUT precision structure drm_color_lut has only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values.
Signed-off-by: Alex Hung
Signed-off-by: Uma Shankar
-bt2020_oetf
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Reviewed-by: Daniel Stone
---
V10:
- Move amdgpu_dm_supported_*_tfs check to Patch 32 (Melissa Wen)
V9:
- Move DRM_COLOROP_1D_CURVE_BT2020_* from middle to end
v8:
- Move BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF) in
From: Harry Wentland
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.
Both are used as encoding functions for video content, and are
therefore defined as OETF (opto-electronic trans
From: Harry Wentland
Add documentation for color pipeline API.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Reviewed-by: Daniel Stone
Reviewed-by: Simon Ser
Reviewed-by: Melissa Wen
---
V9:
- Update documents according to new 3DLUT changes (Simon Ser)
- Spell out the behaviours
here from Patch 32 (Melissa Wen)
v8:
- Move BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF) in amdgpu_dm_supported_blnd_tfs
from "drm/amd/display: Add support for BT.709 and BT.2020 TFs" (Leo Li)
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 20 +--
.../amd/display
Expose a 2nd curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF and program HW to
perform the sRGB Inverse EOTF on the shaper block
when the colorop is not in bypass.
With this change the follow IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf
kms_colorop --run plane-
Expose one 1D curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
the sRGB transform when the colorop is not in bypass.
With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf
The color pipeline now consists of a single color
eason AMD HW hard-codes a PQ
function that is scaled by 125, yielding 80 nit PQ values for
1.0 and 10,000 nits at 125.0.
This patch introduces this scaled PQ EOTF and its inverse as
1D curve types.
Reviewed-by: Simon Ser
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Reviewed-by: Daniel
Expose a 3rd 1D curve colorop, with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program the BLND block
to perform the sRGB transform when the colorop is not in
bypass
With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf-srgb_eotf
The color p
cursor plane does not need to have color pipeline.
Signed-off-by: Alex Hung
Reviewed-by: Daniel Stone
Reviewed-by: Melissa Wen
---
v7:
- Add a commit messages
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/di
From: Harry Wentland
Add the default Bypass pipeline and ensure it passes the
kms_colorop test plane-XR30-XR30-bypass.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Reviewed-by: Daniel Stone
---
v10:
- guard "dm_plane_init_colorops" function when !AMD_PRIVATE_COLOR (Melissa Wen)
.
From: Harry Wentland
Drivers will need to know whether an atomic check/commit
originated from a client with DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
so they can ignore deprecated properties, like COLOR_ENCODING
and COLOR_RANGE.
Pass the plane_color_pipeline bit to drm_atomic_state.
Reviewed-by: Simo
Create a new macro for_each_new_colorop_in_state to access new
drm_colorop_state updated from uapi.
Reviewed-by: Simon Ser
Signed-off-by: Alex Hung
Reviewed-by: Daniel Stone
Reviewed-by: Melissa Wen
---
v10:
- remove duplicated "is useful" in comments
include/drm/drm_atomic.h | 20 +
From: Harry Wentland
While working on the CTM implementation of VKMS I had to ascertain
myself of a few assumptions. One of those is whether drm_fixed.h
treats its numbers using signed-magnitude or twos-complement. It is
twos-complement.
In order to make someone else's day easier I am adding the
From: Harry Wentland
We add two 3x4 matrices into the VKMS color pipeline. The reason
we're adding matrices is so that we can test that application
of a matrix and its inverse yields an output equal to the input
image.
One complication with the matrix implementation has to do with
the fact that
From: Harry Wentland
This patch introduces a VKMS color pipeline that includes two
drm_colorops for named transfer functions. For now the only ones
supported are sRGB EOTF, sRGB Inverse EOTF, and a Linear TF.
We will expand this in the future but I don't want to do so
without accompanyin
From: Harry Wentland
This type is used to support a 3x4 matrix in colorops. A 3x4
matrix uses the last column as a "bias" column. Some HW exposes
support for 3x4. The calculation looks like:
out matrixin
|R| |0 1 2 3 | | R |
|G| = |4 5 6 7 | x | G |
|B| |8 9 10 11| | B
From: Harry Wentland
Two tests are added to VKMS LUT handling:
- linear
- inv_srgb
Reviewed-by: Louis Chauvet
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Reviewed-by: Daniel Stone
---
v7:
- Fix checkpatch warnings (Louis Chauvet)
- Adde a commit messages
- Fix code styles by
From: Harry Wentland
Add kernel doc for drm_colorop objects.
Reviewed-by: Simon Ser
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Reviewed-by: Daniel Stone
Reviewed-by: Melissa Wen
---
v8:
- Move this after "drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE"
(Simon Ser)
From: Harry Wentland
With the introduction of the pre-blending color pipeline we
can no longer have color operations that don't have a clear
position in the color pipeline. We deprecate all existing
plane properties. For upstream drivers those are:
- COLOR_ENCODING
- COLOR_RANGE
Drivers are ex
From: Harry Wentland
We're adding a new enum COLOR PIPELINE property. This
property will have entries for each COLOR PIPELINE by
referencing the DRM object ID of the first drm_colorop
of the pipeline. 0 disables the entire COLOR PIPELINE.
Userspace can use this to discover the available color
pi
From: Harry Wentland
Print atomic state for drm_colorop in debugfs
Reviewed-by: Simon Ser
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Reviewed-by: Daniel Stone
Reviewed-by: Melissa Wen
---
v8:
- Add switch statement to print colorop type (Simon Ser)
v7:
- Add a commit messages
From: Harry Wentland
We want to be able to bypass each colorop at all times.
Introduce a new BYPASS boolean property for this.
Reviewed-by: Simon Ser
Reviewed-by: Louis Chauvet
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Reviewed-by: Daniel Stone
Reviewed-by: Melissa Wen
---
v6:
From: Harry Wentland
Add a new drm_colorop with DRM_COLOROP_1D_CURVE with two subtypes:
DRM_COLOROP_1D_CURVE_SRGB_EOTF and DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF.
Reviewed-by: Simon Ser
Reviewed-by: Louis Chauvet
Signed-off-by: Harry Wentland
Co-developed-by: Alex Hung
Signed-off-by: Alex Hung
From: Harry Wentland
Add a read-only TYPE property. The TYPE specifies the colorop
type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT,
etc.
For now we're only introducing an enumerated 1D LUT type to
illustrate the concept.
Reviewed-by: Simon Ser
Reviewed-by: Louis Chauvet
Signed-of
colorop_list kernel doc
- Add kernel doc for color_pipeline
- drop unused drm_colorop_destroy_state
- drop drm_colorop_init, to be introduced in later patch
when used
- Add kernel docs
- Drop TODOs
v4:
- Drop IOCTL definitions (Pekka)
- add missing declaration (Chaitanya Kumar Borah)
This is an RFC set for a color pipeline API, along with implementations
in VKMS and amdgpu. It is tested with a set of IGT tests that can be
found at [1]. The IGT tests run a pixel-by-pixel comparison with an
allowable delta variation as the goal for these transformations is
perceptual correctness,
From: Harry Wentland
Debugging LUT math is much easier when we can unit test
it. Add kunit functionality to VKMS and add tests for
- get_lut_index
- lerp_u16
Reviewed-by: Louis Chauvet
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Cc: Arthur Grillo
Reviewed-by: Daniel Stone
---
v
From: Harry Wentland
CTM values are defined as signed-magnitude values. Add
a helper that converts from CTM signed-magnitude fixed
point value to the twos-complement value used by
drm_fixed.
Reviewed-by: Louis Chauvet
Signed-off-by: Harry Wentland
Reviewed-by: Daniel Stone
Reviewed-by: Meliss
u...@arm.com; sashamcint...@google.com; Borah, Chaitanya
> > Kumar ; louis.chau...@bootlin.com;
> > Daniel Stone
> > Subject: [PATCH V9 16/43] drm/colorop: Add 3x4 CTM type
> >
> > From: Harry Wentland
> >
> > This type is used to support a 3x4 matri
om; dan...@ffwll.ch; Shankar, Uma
> ; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; Borah, Chaitanya
> Kumar ; louis.chau...@bootlin.com;
> Daniel Stone
> Subject: [PATCH V9 16
gt; sashamcint...@google.com; Borah, Chaitanya Kumar
> > ; louis.chau...@bootlin.com
> > Subject: Re: [PATCH V8 32/43] drm/colorop: Add 1D Curve Custom LUT type
> >
> >
> >
> > On 2025-06-03 06:51, Pekka Paalanen wrote:
> > > On Tue, 3 Jun 2025 08:30:23 +0
m76.com;
> dan...@ffwll.ch; quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; mar...@marcan.st; liviu.du...@arm.com;
> sashamcint...@google.com; Borah, Chaitanya Kumar
> ; louis.chau...@bootlin.com
> Subject: Re: [PATCH V8 32/43] drm/colorop: Add 1D C
@ffwll.ch; quic_nas...@quicinc.com;
>>> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; mar...@marcan.st;
>>> liviu.du...@arm.com; sashamcint...@google.com; Borah, Chaitanya Kumar
>>> ; louis.chau...@bootlin.com
>>> Subject: Re: [PATCH V8 32/43] drm/colorop: Add 1D Cu
arcan.st;
> > liviu.du...@arm.com; sashamcint...@google.com; Borah, Chaitanya Kumar
> > ; louis.chau...@bootlin.com
> > Subject: Re: [PATCH V8 32/43] drm/colorop: Add 1D Curve Custom LUT type
> >
> > On Thu, 22 May 2025 11:33:00 +
> > "Shankar, Uma" wro
.@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; Borah, Chaitanya Kumar
> ; louis.chau...@bootlin.com
> Subject: Re: [PATCH V8 32/43
o make it future proof.
> Reference: https://patchwork.freedesktop.org/patch/642592/?series=129811&rev=4
>
> +/**
> + * struct drm_color_lut_32 - Represents high precision lut values
> + *
> + * Creating 32 bit palette entries for better data
> + * precision. This will be requ
On 2025-05-22 11:27, Pekka Paalanen wrote:
> On Thu, 22 May 2025 09:54:50 -0400
> Harry Wentland wrote:
>
>> On 2025-05-22 09:49, Simon Ser wrote:
>>> On Thursday, May 22nd, 2025 at 15:28, Harry Wentland
>>> wrote:
>>>
>> What we should
>> do is reject YCbCr-type buffers with the
On Thu, 22 May 2025 09:54:50 -0400
Harry Wentland wrote:
> On 2025-05-22 09:49, Simon Ser wrote:
> > On Thursday, May 22nd, 2025 at 15:28, Harry Wentland
> > wrote:
> >
> What we should
> do is reject YCbCr-type buffers with the color pipeline until we
> implement support for
On 2025-05-22 09:49, Simon Ser wrote:
> On Thursday, May 22nd, 2025 at 15:28, Harry Wentland
> wrote:
>
What we should
do is reject YCbCr-type buffers with the color pipeline until we
implement support for COLOR_ENCODING and COLOR_RANGE as a new
CSC colorop.
>>>
>>> Reject
On Thursday, May 22nd, 2025 at 15:28, Harry Wentland
wrote:
> > > What we should
> > > do is reject YCbCr-type buffers with the color pipeline until we
> > > implement support for COLOR_ENCODING and COLOR_RANGE as a new
> > > CSC colorop.
> >
> > Rejecting is fine, but is implementing COLOR_ENC
On 2025-05-22 03:57, Pekka Paalanen wrote:
> On Wed, 21 May 2025 15:48:00 -0400
> Harry Wentland wrote:
>
>> On 2025-05-17 07:51, Xaver Hugl wrote:
>>> Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro
>>> :
On 5/15/25 15:39, Daniel Stone wrote:
> Hi,
>
quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; Borah, Chaitanya Kumar
> ; louis.chau...@bootlin.com
> Subject: Re: [PATCH V8 40/43] drm/colorop: Add 3D LUT support to color
> pipeline
>
&
e.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; Borah, Chaitanya Kumar
> ; louis.chau...@bootlin.com
> Subject: Re: [P
On Wednesday, May 21st, 2025 at 21:18, Harry Wentland
wrote:
> On 2025-05-20 16:13, Harry Wentland wrote:
>
> > On 2025-05-19 19:43, Simon Ser wrote:
> >
> > > On Sunday, May 18th, 2025 at 00:32, Xaver Hugl xaver.h...@gmail.com wrote:
> > >
> > > > > We can always make the property mutable on
On Wed, 21 May 2025 15:48:00 -0400
Harry Wentland wrote:
> On 2025-05-17 07:51, Xaver Hugl wrote:
> > Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro
> > :
> >>
> >>
> >>
> >> On 5/15/25 15:39, Daniel Stone wrote:
> >>> Hi,
> >>>
> >>> On Thu, 15 May 2025 at 19:02, Harry Wentland
On 2025-05-20 16:13, Harry Wentland wrote:
>
>
> On 2025-05-19 19:43, Simon Ser wrote:
>> On Sunday, May 18th, 2025 at 00:32, Xaver Hugl wrote:
>>
We can always make the property mutable on drivers that support it in
>>>
the future, much like the zpos property. I think we should kee
On 2025-05-17 07:51, Xaver Hugl wrote:
> Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro
> :
>>
>>
>>
>> On 5/15/25 15:39, Daniel Stone wrote:
>>> Hi,
>>>
>>> On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
On 2025-05-15 13:19, Daniel Stone wrote:
> Yeah, the Weston patch
On 2025-05-19 19:43, Simon Ser wrote:
> On Sunday, May 18th, 2025 at 00:32, Xaver Hugl wrote:
>
>>> We can always make the property mutable on drivers that support it in
>>
>>> the future, much like the zpos property. I think we should keep it
>>> immutable for now.
>>
>> Sure, but I don't see
On Sunday, May 18th, 2025 at 00:32, Xaver Hugl wrote:
> > We can always make the property mutable on drivers that support it in
>
> > the future, much like the zpos property. I think we should keep it
> > immutable for now.
>
> Sure, but I don't see any reason for immutability with an enum
> pr
On 5/17/25 2:22 AM, Xaver Hugl wrote:
Am Do., 27. März 2025 um 00:58 Uhr schrieb Alex Hung :
It is to be used to enable HDR by allowing userpace to create and pass
3D LUTs to kernel and hardware.
new drm_colorop_type: DRM_COLOROP_3D_LUT.
Signed-off-by: Alex Hung
---
v8:
- Fix typo in subj
> We can always make the property mutable on drivers that support it in
> the future, much like the zpos property. I think we should keep it
> immutable for now.
Sure, but I don't see any reason for immutability with an enum
property - it can just limit the possible values to what it supports,
and
On Saturday, May 17th, 2025 at 03:23, Xaver Hugl wrote:
> Do we ever expect this to be something with multiple options that
> userspace could select? I think it would be good to keep our options
> open and make this property not immutable (properties that are
> sometimes but not always immutable
Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro
:
>
>
>
> On 5/15/25 15:39, Daniel Stone wrote:
> > Hi,
> >
> > On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
> >> On 2025-05-15 13:19, Daniel Stone wrote:
> >>> Yeah, the Weston patches are marching on. We've still been doing a
> >>>
Am Do., 27. März 2025 um 00:58 Uhr schrieb Alex Hung :
>
> It is to be used to enable HDR by allowing userpace to create and pass
> 3D LUTs to kernel and hardware.
>
> new drm_colorop_type: DRM_COLOROP_3D_LUT.
>
> Signed-off-by: Alex Hung
> ---
> v8:
> - Fix typo in subject (Simon Ser)
> - Updat
On 5/15/25 15:39, Daniel Stone wrote:
> Hi,
>
> On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
>> On 2025-05-15 13:19, Daniel Stone wrote:
>>> Yeah, the Weston patches are marching on. We've still been doing a
>>> little bit of cleanup and prep work in the background to land them,
>>> but
Hi,
On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
> On 2025-05-15 13:19, Daniel Stone wrote:
> > Yeah, the Weston patches are marching on. We've still been doing a
> > little bit of cleanup and prep work in the background to land them,
> > but we also can't land them until the kernel lands.
Hi,
On Thu, 15 May 2025 at 15:11, Harry Wentland wrote:
> On 2025-05-15 05:45, Simon Ser wrote:
> > I've reviewed all of the core DRM patches :)
> >
> > Have there been updates from user-space implementations?
>
> I know Leandro has been working on Weston to make use of
> this and last year Xaver
On 2025-05-15 13:19, Daniel Stone wrote:
> Hi,
>
> On Thu, 15 May 2025 at 15:11, Harry Wentland wrote:
>> On 2025-05-15 05:45, Simon Ser wrote:
>>> I've reviewed all of the core DRM patches :)
>>>
>>> Have there been updates from user-space implementations?
>>
>> I know Leandro has been workin
On Thursday, May 15th, 2025 at 16:11, Harry Wentland
wrote:
> > Have there been updates from user-space implementations?
>
> I know Leandro has been working on Weston to make use of
> this and last year Xaver had a prototype in kwin.
Cool!
> Ideally we'd have gamescope adopt it and switch off
On 2025-05-15 05:45, Simon Ser wrote:
> I've reviewed all of the core DRM patches :)
>
> Have there been updates from user-space implementations?
I know Leandro has been working on Weston to make use of
this and last year Xaver had a prototype in kwin.
Ideally we'd have gamescope adopt it and
On Tue, 13 May 2025 16:39:51 -0400
Harry Wentland wrote:
> On 2025-05-13 11:36, Melissa Wen wrote:
> > On 05/13, Pekka Paalanen wrote:
> >> On Mon, 12 May 2025 15:50:17 -0300
> >> Melissa Wen wrote:
> >>
> >>> On 04/29, Alex Hung wrote:
> Expose one 1D curve colorop with support for
>
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
1 - 100 of 7042 matches
Mail list logo
