On Friday, August 1st, 2025 at 00:12, Nícolas "F. R. A. Prado"
wrote:
> This function implies it only cleans up the colorops in the color
> pipeline of a specific plane, but it actually cleans up all colorops in
> the drm_mode_config of a device.
Good catch! Would make more sense to take a drm_
On 7/9/25 13:56, Melissa Wen wrote:
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 example.
- https://lore.kernel.o
On Saturday, August 2nd, 2025 at 03:49, Alex Hung wrote:
> It may be better to change it now if we know it needs changing in the
> future.
It would become mutable only for hardware that supports switching the
interpolation. It would remain immutable otherwise.
Immutable is an indication that us
Hi Simon,
It may be better to change it now if we know it needs changing in the
future.
Hi Xaver,
Do you think this need to be immutable or mutable? Do you believe this
need to be mutable?
On 7/9/25 14:30, Simon Ser wrote:
On Tuesday, June 17th, 2025 at 06:27, Alex Hung wrote:
- 1D LU
On Mon, 2025-06-16 at 22:17 -0600, Alex Hung wrote:
> 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.
>
> Si
;
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,
1 - 100 of 5480 matches
Mail list logo
