;
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
On 7/9/25 14:49, Borah, Chaitanya Kumar wrote:
Hi Alex,
-Original Message-
From: Alex Hung
Sent: Tuesday, June 17, 2025 9:47 AM
To: dri-de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: wayland-devel@lists.freedesktop.org; harry.wentl...@amd.com;
alex.h...@amd.com; leo.
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.
On 17/06/2025 00:17, Alex Hung wrote:
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 ins
On 17/06/2025 00:17, Alex Hung wrote:
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/dis
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
Hi Alex,
> -Original Message-
> From: Alex Hung
> Sent: Tuesday, June 17, 2025 9:47 AM
> To: dri-de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: wayland-devel@lists.freedesktop.org; harry.wentl...@amd.com;
> alex.h...@amd.com; leo@amd.com; ville.syrj...@linux.intel.co
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 {
> _
Hi Alex,
On 17/06/25 01:16, Alex Hung wrote:
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
C
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
Hi Alex,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.16-rc2]
[cannot apply to drm-exynos/exynos-drm-next drm/drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-misc/drm-misc-next
drm-tip/drm-t
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
, 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
On Mon, 16 Jun 2025 11:30:23 +
"Borah, Chaitanya Kumar" wrote:
> > -Original Message-
> > From: Alex Hung
> > Sent: Wednesday, April 30, 2025 6:41 AM
> > To: dri-de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > Cc: wayland-devel@lists.freedesktop.org; harry.wentl...@amd
> -Original Message-
> From: Alex Hung
> Sent: Wednesday, April 30, 2025 6:41 AM
> To: dri-de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: wayland-devel@lists.freedesktop.org; harry.wentl...@amd.com;
> alex.h...@amd.com; leo@amd.com; ville.syrj...@linux.intel.com;
>
gt; > ago...@nvidia.com; jos...@froggi.es; mdaen...@redhat.com;
> > aleix...@kde.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;
> &
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
On Thu, 22 May 2025 11:33:00 +
"Shankar, Uma" wrote:
> One request though: Can we enhance the lut samples from existing 16bits to
> 32bits as lut precision is
> going to be more than 16 in certain hardware. While adding the new UAPI, lets
> extend this to 32 to make it future proof.
> Refer
On Thu, 22 May 2025 21:02:48 +
"Sloane, Brandon" wrote:
> > Could you explain more of your actual use cases? Maybe people would
> > have better ideas how to solve them.
>
> We are focused on cross domain and multi-level systems built using
> SELinux as a core part of their security archite
ing is the source wl_data_source; this does require explicit compositor
support to provide. The wl_surface was relevent for screenshots.
-- Brandon
> -Original Message-
> From: Pekka Paalanen
> Sent: Thursday, May 22, 2025 4:58 AM
> To: Sloane, Brandon
> Cc: wayland-devel
Thanks for the feedback! It seems like everybody is on board for
skipping alphas/betas, so let's try that. We can always go back to the
old process later if we realize it was valuable.
Simon
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 11:49:34 +0200
Jonas Ådahl wrote:
> On Wed, May 21, 2025 at 05:43:09AM -0400, Neal Gompa wrote:
> > On Tue, May 20, 2025 at 4:03 PM Simon Ser wrote:
> > >
> > > I would suggest to drop the alphas/betas from the release process, ie.
> > > go straight to RC1. The process woul
On Tue, 20 May 2025 19:11:06 +
"Sloane, Brandon" wrote:
> > -Original Message-
> > From: Pekka Paalanen
> > Sent: Tuesday, May 20, 2025 4:58 AM
> > To: Sloane, Brandon
> > Cc: wayland-devel@lists.freedesktop.org
> > Subject: Re: [RFC
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
Hi,
Looking at the recent history, I think we could have cut a release at any point
in time and there wouldn't have been any issues with the release. So yes, I do
think that simplifying and shortening the release process makes a lot of sense!
On Tue, May 20, 2025, at 10:03 PM, Simon Ser wrote:
From: Alyssa Ross
Sent: Wednesday, May 21, 2025 1:28 PM
To: Sloane, Brandon
Cc: wayland-devel@lists.freedesktop.org; Pekka Paalanen
Subject: RE: [RFC] Wayland Security Modules
"Sloane, Brandon" writes:
>> -Original Message-
>> From: Pekka Paalanen
>
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
"Sloane, Brandon" writes:
> I'm not sure how the pop-os/cosmic-comp PR is relevent. It seems to be about
> exposing cosmic-comp as a library in general. While potentially useful,
> several other compositors have been doing that for a while, and it doesn't
> seem inform security decisions.
Yea
"Sloane, Brandon" writes:
>> -Original Message-
>> From: Pekka Paalanen
>> Sent: Tuesday, May 20, 2025 4:58 AM
>> To: Sloane, Brandon
>> Cc: wayland-devel@lists.freedesktop.org
>> Subject: Re: [RFC] Wayland Security Modules
>>
>&
On Wed, May 21, 2025 at 05:43:09AM -0400, Neal Gompa wrote:
> On Tue, May 20, 2025 at 4:03 PM Simon Ser wrote:
> >
> > Hi all,
> >
> > With years passing by, development in the main Wayland repository has
> > slowed down quite a bit, activity has moved over to wayland-protocols
> > and compositors
On Wednesday, May 21st, 2025 at 11:43, Neal Gompa wrote:
> Funnily enough, I think wlroots should probably have them since
> wlroots releases are so highly disruptive for basically every
> consumer...
wlroots has them since the last release.
> That said, going straight to RCs for libwayland its
On Tue, May 20, 2025 at 08:03:02PM +, Simon Ser wrote:
> Hi all,
>
> With years passing by, development in the main Wayland repository has
> slowed down quite a bit, activity has moved over to wayland-protocols
> and compositors. However, cutting a new Wayland release is still a
> heavyweight
On Tue, May 20, 2025 at 4:03 PM Simon Ser wrote:
>
> Hi all,
>
> With years passing by, development in the main Wayland repository has
> slowed down quite a bit, activity has moved over to wayland-protocols
> and compositors. However, cutting a new Wayland release is still a
> heavyweight process:
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
> -Original Message-
> From: Pekka Paalanen
> Sent: Tuesday, May 20, 2025 4:58 AM
> To: Sloane, Brandon
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: [RFC] Wayland Security Modules
>
> On Mon, 19 May 2025 15:48:04 +
> "Sloane, Brandon&quo
On Mon, 19 May 2025 15:48:04 +
"Sloane, Brandon" wrote:
> Hello,
>
> I've spent the past few months prototyping a security modules system
> for Wayland. Our specific motivation for this is to support SELinux
> integration to meet some rather unique security requirements.
> However, what we a
On Sun, 18 May 2025 17:10:36 + (UTC)
Pete wrote:
> Dear Wayland protocol developers, please improve Wayland's privacy
> and security model against recent screenshot and similar attacks.
Hi,
what attacks are you referring to?
> Use
> a screenshot and recording security model where applicati
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
Hello there,
On 18 May 2025, at 19:10, Pete wrote:
> Also no autorun of insertable media by default. Ask what to do (for audio or
> video media and maybe open the designated file explorer for data carrying
> media) for the default settings.
I really wish Wayland was named something like SUGCP
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
You may find one of these projects helpful:
https://github.com/rvaiya/warpd
https://github.com/moverest/wl-kbptr
https://github.com/gabcoh/keynav-wayland
https://github.com/tadeokondrak/waypoint
I believe all of them support the virtual-pointer protocol.
Mine (waypoint) supports libei as well, bu
Hi Zarif,
On Fri, 16 May 2025 at 11:54, Zarif Atai wrote:
> Dear subscribers of wayland-devel,
>
> As a Vim motions enthusiast, it bothers me that there are too many
> situations where I'm forced to use a pointer input device (e.g. a mouse) to
> perform an action. I looked around to see if anyon
On Wed, May 14, 2025 at 11:27:50PM +, Zarif Atai wrote:
> Dear subscribers of wayland-devel,
>
> As a Vim motions enthusiast, it bothers me that there are too many situations
> where I'm forced to use a pointer input device (e.g. a mouse) to perform an
> action. I looked around to see if any
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
I've reviewed all of the core DRM patches :)
Have there been updates from user-space implementations?
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
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
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
the sRGB t
On 04/29, Alex Hung wrote:
> 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 transfo
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
> > > DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
> > > the sRGB transform when the colorop is not in bypass.
On 05/12, Alex Hung wrote:
>
>
> On 5/12/25 18:52, Melissa Wen wrote:
> > On 04/29, Alex Hung wrote:
> > > 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 color
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
> > 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 te
On 4/25/25 07:50, Leandro Ribeiro wrote:
On 3/26/25 20:47, Alex Hung wrote:
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
On 5/12/25 18:52, Melissa Wen wrote:
On 04/29, Alex Hung wrote:
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 H
On 04/29, Alex Hung wrote:
> 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-b
On 29/04/2025 22:11, Alex Hung wrote:
Typo in the commit msg: mutliplier -> multiplier
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.
Review
On 04/29, Alex Hung wrote:
> From: Harry Wentland
>
> This adds support for the BT.709/BT.2020 transfer functions
> on all current 1D curve plane colorops, i.e., on DEGAM, SHAPER,
> and BLND blocks.
>
> With this change the following IGT subtests pass:
> kms_colorop --run plane-XR30-XR30-bt2020_
On 04/29, 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
On 04/29, Alex Hung wrote:
> 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
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_plane
On 04/29, Alex Hung wrote:
> 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
> ---
> include/drm/drm_atomic.h | 20
> 1 file changed, 20
Hi Alex,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on next-20250507]
[cannot apply to linus/master drm/drm-next drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm-misc/drm-misc-next drm-tip/dr
Hi Alex,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on next-20250507]
[cannot apply to linus/master v6.15-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch,
On 3/26/25 20:47, Alex Hung wrote:
> 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)
> - Update documentation f
how these functions will be
adapted for post-blending. Maybe the functions will be re-used and the
plane argument dropped, in which case it'd make more sense to keep the
current name. We don't know yet.
On Tue, 15 Apr 2025 11:29:10 -0400
Harry Wentland wrote:
> On 2025-04-10 03:53, Pekka Paalanen wrote:
> > On Tue, 8 Apr 2025 13:30:46 -0400
> > Harry Wentland wrote:
> >
> >> On 2025-04-08 12:40, Daniel Stone wrote:
> >>> Hi there,
> >>>
> >>> On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
> > The 3x4 CTM colorop is not yet explicit on whether it clamps its inputs
> > or outputs. Should all colorops be explicit about it?
> >
>
> Do we expect all HW/drivers to be able to support the same behavior?
> Is this critical to using the colorop?
It doesn't need to be the same on all hardware,
On 4/8/2025 10:10 PM, Daniel Stone wrote:
As it stands, I've gone through the implementation pretty thoroughly,
as well as our use of it in Weston. I'm happy with how it looks for
pre-blend, and I'm even happier that the implementation is written to
apply easily to apply to post-blend CRTC pip
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] drm/color
On Tuesday, April 15th, 2025 at 17:05, Harry Wentland
wrote:
> > > > We want to have just one change in the way we expose the hardware
> > > > capabilities else all looks good in general.
> > >
> > > I would really recommend leaving this as a follow-up extension. It's a
> > > complicated
> > >
ago...@nvidia.com; jos...@froggi.es;
>> mdaen...@redhat.com; aleix...@kde.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...@goog
On 2025-04-10 03:53, Pekka Paalanen wrote:
> On Tue, 8 Apr 2025 13:30:46 -0400
> Harry Wentland wrote:
>
>> On 2025-04-08 12:40, Daniel Stone wrote:
>>> Hi there,
>>>
>>> On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
On Tuesday, April 1st, 2025 at 17:14, Daniel Stone
wrote:
>
1 - 100 of 5475 matches
Mail list logo
