Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Mon, 15 Apr 2024 18:33:39 -0400 Leo Li wrote: > On 2024-04-15 04:19, Pekka Paalanen wrote: > > On Fri, 12 Apr 2024 16:14:28 -0400 > > Leo Li wrote: > > > >> On 2024-04-12 11:31, Alex Deucher wrote: > >>> On Fri, Apr 12, 20

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Fri, 12 Apr 2024 16:14:28 -0400 Leo Li wrote: > On 2024-04-12 11:31, Alex Deucher wrote: > > On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen > > wrote: > >> > >> On Fri, 12 Apr 2024 10:28:52 -0400 > >> Leo Li wrote: > >> > >>

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: > On 2024-04-12 04:03, Pekka Paalanen wrote: > > On Thu, 11 Apr 2024 16:33:57 -0400 > > Leo Li wrote: > > ... > >> That begs the question of what can be nailed down and what can left to > >> independ

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: > On 2024-04-04 10:22, Marius Vlad wrote: > > On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: > >> > > Hi all, > >> > >> On 2024-04-04 06:24, Pekka Paalanen wrote: > >>>

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

On Wed, 3 Apr 2024 17:32:46 -0400 Leo Li wrote: > On 2024-03-28 10:33, Pekka Paalanen wrote: > > On Fri, 15 Mar 2024 13:09:56 -0400 > > wrote: > > > >> From: Leo Li > >> > >> These patches aim to make the amdgpgu KMS driver play nicer with

Re: 2024 X.Org Foundation Membership deadline for voting in the election

On Tue, 26 Mar 2024 11:42:48 -0400 Christopher Michael wrote: > The 2024 X.Org Foundation membership renewal period has been extended > one additional week and elections will start the following week on 01 > April 2024. > > Please note that only current members can vote in the upcoming

Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

q > Some links to provide context and details: > * What is underlay?: > https://gitlab.freedesktop.org/emersion/libliftoff/-/issues/76 > * Discussion on how to implement underlay on Weston: > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258#note_2325164 > >

Re: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode

On Fri, 15 Mar 2024 13:09:57 -0400 wrote: > From: Leo Li > > [Why] > > DCN is the display hardware for amdgpu. DRM planes are backed by DCN > hardware pipes, which carry pixel data from one end (memory), to the > other (output encoder). > > Each DCN pipe has the ability to blend in a cursor

Re: [PATCH 2/2] drm/amd/display: Move PRIMARY plane zpos higher

RIMARY. > > [How] > > Assign a zpos = #no of OVERLAY planes to the PRIMARY plane. Then, clean > up any assumptions in the driver of PRIMARY plane having the lowest > zpos. This sounds good to me too. I suppose that means Acked-by: Pekka Paalanen for both patches. Or

Re: [RFC PATCH v4 23/42] drm/vkms: add 3x4 matrix in color pipeline

On Mon, 26 Feb 2024 16:10:37 -0500 Harry Wentland wrote: > 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. You will test also cases where

Re: [RFC PATCH v4 24/42] drm/tests: Add a few tests around drm_fixed.h

On Mon, 26 Feb 2024 16:10:38 -0500 Harry Wentland wrote: > 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

Re: [RFC PATCH v4 25/42] drm/vkms: Add tests for CTM handling

On Mon, 26 Feb 2024 16:10:39 -0500 Harry Wentland wrote: > 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. > > v4: > -

Re: [RFC PATCH v4 22/42] drm/vkms: Use s32 for internal color pipeline precision

On Mon, 26 Feb 2024 16:10:36 -0500 Harry Wentland wrote: > 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

Re: [RFC PATCH v4 17/42] drm/vkms: Add enumerated 1D curve colorop

On Mon, 26 Feb 2024 16:10:31 -0500 Harry Wentland wrote: > 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

Re: [RFC PATCH v4 10/42] drm/colorop: Add TYPE property

On Mon, 26 Feb 2024 16:10:24 -0500 Harry Wentland wrote: > Add a read-only TYPE property. The TYPE specifies the colorop > type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT, > etc. > > v4: > - Use enum property for TYPE (Pekka) > > v3: > - Make TYPE a range property > - Move enum

Re: [RFC PATCH v4 10/42] drm/colorop: Add TYPE property

On Tue, 12 Mar 2024 15:15:13 + Simon Ser wrote: > On Tuesday, March 12th, 2024 at 16:02, Pekka Paalanen > wrote: > > > This list here is the list of all values the enum could take, right? > > Should it not be just the one value it's going to have? It'll never > &g

Re: [RFC PATCH v4 03/42] drm: Correctly round for fixp2int_round

On Mon, 26 Feb 2024 16:10:17 -0500 Harry Wentland wrote: > A value of 0x8000 and higher should round up, and > below should round down. VKMS Kunit tests for lerp_u16 > showed that this is not the case. Fix it. > > 1 << (DRM_FIXED_POINT_HALF - 1) = > 1 << 15 = 0x8000 > > This is not 0.5,

Re: [RFC PATCH v4 06/42] drm/vkms: Add kunit tests for VKMS LUT handling

On Mon, 26 Feb 2024 16:10:20 -0500 Harry Wentland wrote: > 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 > > v4: > - Test the critical points of the lerp function (Pekka) > > v3: > - Use

Re: [RFC PATCH v4 08/42] drm/doc/rfc: Describe why prescriptive color pipeline is needed

pecially if > + they require you to combine multiple hardware blocks. > + > +- Design new colorops as prescriptive, not descriptive; by the > + mathematical formula, not by the assumed input and output. > + > +A defined colorop type must be deterministic. The exact behavior of the > +colorop must be documented entirely, whether via a mathematical formula > +or some other description. Its operation can depend only on its > +properties and input and nothing else, allowed error tolerance > +notwithstanding. > + > + > +Driver Forward/Backward Compatibility > += > + > +As this is uAPI drivers can't regress color pipelines that have been > +introduced for a given HW generation. New HW generations are free to > +abandon color pipelines advertised for previous generations. > +Nevertheless, it can be beneficial to carry support for existing color > +pipelines forward as those will likely already have support in DRM > +clients. > + > +Introducing new colorops to a pipeline is fine, as long as they can be > +bypassed or are purely informational. DRM clients implementing support > +for the pipeline can always skip unknown properties as long as they can > +be confident that doing so will not cause unexpected results. > + > +If a new colorop doesn't fall into one of the above categories > +(bypassable or informational) the modified pipeline would be unusable > +for user space. In this case a new pipeline should be defined. > + > + > +References > +== > + > +1. > https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1QWn488=@emersion.fr/ > \ No newline at end of file All in all, I think this is good enough to have my Acked-by: Pekka Paalanen in spite of the comments I had. They are just fine tuning. Thanks, pq pgpAL0MSLPKap.pgp Description: OpenPGP digital signature

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

On Fri, 16 Feb 2024 10:32:10 -0600 Mario Limonciello wrote: > On 2/16/2024 10:13, Harry Wentland wrote: > > > > > > On 2024-02-16 11:11, Harry Wentland wrote: > >> > >> > >> On 2024-02-16 10:42, Pekka Paalanen wrote: > >>> On

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

On Fri, 16 Feb 2024 09:33:47 -0500 Harry Wentland wrote: > On 2024-02-16 03:19, Pekka Paalanen wrote: > > On Fri, 2 Feb 2024 10:28:35 -0500 > > Hamza Mahfooz wrote: > > > >> We want programs besides the compositor to be able to enable or disable &g

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

On Fri, 2 Feb 2024 10:28:35 -0500 Hamza Mahfooz wrote: > We want programs besides the compositor to be able to enable or disable > panel power saving features. Could you also explain why, in the commit message, please? It is unexpected for arbitrary programs to be able to override the KMS

Re: [PATCH v3 1/3] drm/atomic: Allow drivers to write their own plane check for async flips

On Sun, 28 Jan 2024 18:25:13 -0300 André Almeida wrote: > Some hardware are more flexible on what they can flip asynchronously, so > rework the plane check so drivers can implement their own check, lifting > up some of the restrictions. > > Signed-off-by: André Almeida > --- > v3: no changes >

Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace

On Wed, 17 Jan 2024 12:58:15 + Andri Yngvason wrote: > mið., 17. jan. 2024 kl. 09:21 skrifaði Pekka Paalanen : ... > > EDID and DisplayID standards also evolve. The kernel could be behind > > userspace in chasing them, which was the reason why the kernel does n

Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace

On Tue, 16 Jan 2024 14:11:43 + Andri Yngvason wrote: > þri., 16. jan. 2024 kl. 13:29 skrifaði Sebastian Wick > : > > > > On Tue, Jan 16, 2024 at 01:13:13PM +, Andri Yngvason wrote: > [...] > > > şri., 16. jan. 2024 kl. 11:42 skrifaği Sebastian Wick > > > : > > > > > > > > On Mon, Jan

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

m async "cursor commits" in the mean time? Thanks, pq > Am Di., 16. Jan. 2024 um 14:35 Uhr schrieb André Almeida < > andrealm...@igalia.com>: > > > + Joshua > > > > Em 16/01/2024 10:14, Pekka Paalanen escreveu: > > > On Tue, 16 Jan 2024 0

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

On Tue, 16 Jan 2024 08:50:59 -0300 André Almeida wrote: > Hi Pekka, > > Em 16/01/2024 06:45, Pekka Paalanen escreveu: > > On Tue, 16 Jan 2024 01:51:57 -0300 > > André Almeida wrote: > > > >> Hi, > >> > >> AMD hardware can do more on the

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

On Tue, 16 Jan 2024 01:51:57 -0300 André Almeida wrote: > Hi, > > AMD hardware can do more on the async flip path than just the primary plane, > so > to lift up the current restrictions, this patchset allows drivers to write > their > own check for planes for async flips. Hi, what's the

Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set

On Mon, 13 Nov 2023 09:44:15 + Simon Ser wrote: > On Monday, November 13th, 2023 at 10:38, Pekka Paalanen > wrote: > > > On Mon, 13 Nov 2023 09:18:39 + > > Simon Ser cont...@emersion.fr wrote: > > > > > On Monday, October 23rd, 2023 at

Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set

On Mon, 13 Nov 2023 09:18:39 + Simon Ser wrote: > On Monday, October 23rd, 2023 at 10:25, Simon Ser wrote: > > > > > > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC > > > > > > > > > > > is allowed to > > > > > > > > > > > +effectively change only the FB_ID property

Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set

On Mon, 16 Oct 2023 15:42:16 +0200 André Almeida wrote: > Hi Pekka, > > On 10/16/23 14:18, Pekka Paalanen wrote: > > On Mon, 16 Oct 2023 12:52:32 +0200 > > André Almeida wrote: > > > >> Hi Michel, > >> > >> On 8/17/23 12:37, Michel Dänze

Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set

On Mon, 16 Oct 2023 12:52:32 +0200 André Almeida wrote: > Hi Michel, > > On 8/17/23 12:37, Michel Dänzer wrote: > > On 8/15/23 20:57, André Almeida wrote: > >> From: Pekka Paalanen > >> > >> Specify how the atomic state is maintained between usersp

Re: [PATCH v3 07/32] drm/amd/display: document AMDGPU pre-defined transfer functions

On Thu, 28 Sep 2023 16:16:57 -0400 Harry Wentland wrote: > On 2023-09-25 15:49, Melissa Wen wrote: > > Brief documentation about pre-defined transfer function usage on AMD > > display driver and standardized EOTFs and inverse EOTFs. > > > > v3: > > - Document BT709 OETF (Pekka) > > - Fix

Re: [PATCH v2 07/34] drm/amd/display: explicitly define EOTF and inverse EOTF

On Thu, 7 Sep 2023 10:10:50 -0400 Harry Wentland wrote: > On 2023-09-07 03:49, Pekka Paalanen wrote: > > On Wed, 6 Sep 2023 16:15:10 -0400 > > Harry Wentland wrote: > > > >> On 2023-08-25 10:18, Melissa Wen wrote: > >>> On 08/22, Pekka Paalanen w

Re: [PATCH v2 07/34] drm/amd/display: explicitly define EOTF and inverse EOTF

On Wed, 6 Sep 2023 16:15:10 -0400 Harry Wentland wrote: > On 2023-08-25 10:18, Melissa Wen wrote: > > On 08/22, Pekka Paalanen wrote: > >> On Thu, 10 Aug 2023 15:02:47 -0100 > >> Melissa Wen wrote: > >> > >>> Instead of relying o

Re: [PATCH v2 10/34] drm/amd/display: add plane 3D LUT driver-specific properties

On Wed, 6 Sep 2023 15:30:04 -0400 Harry Wentland wrote: > On 2023-08-10 12:02, Melissa Wen wrote: > > Add 3D LUT property for plane gamma correction using a 3D lookup table. > > Since a 3D LUT has a limited number of entries in each dimension we want > > to use them in an optimal fashion. This

Re: [PATCH v2 19/34] drm/amd/display: decouple steps for mapping CRTC degamma to DC plane

On Mon, 28 Aug 2023 12:56:04 -0100 Melissa Wen wrote: > On 08/28, Pekka Paalanen wrote: > > On Mon, 28 Aug 2023 09:45:44 +0100 > > Joshua Ashton wrote: > > > > > Degamma has always been on the plane on AMD. CRTC DEGAMMA_LUT has actually > > > just be

Re: [PATCH v2 31/34] drm/amd/display: set stream gamut remap matrix to MPC for DCN301

On Fri, 25 Aug 2023 13:37:08 -0100 Melissa Wen wrote: > On 08/22, Pekka Paalanen wrote: > > On Thu, 10 Aug 2023 15:03:11 -0100 > > Melissa Wen wrote: > > > > > dc->caps.color.mpc.gamut_remap says there is a post-blending color block > > > for gamut

Re: [PATCH v2 19/34] drm/amd/display: decouple steps for mapping CRTC degamma to DC plane

es anyone know of any doc about that? If drivers do not agree on the behaviour of a KMS property, then that property is useless for generic userspace. Thanks, pq > On Tuesday, 22 August 2023, Pekka Paalanen > wrote: > > On Thu, 10 Aug 2023 15:02:59 -0100 > > Melissa Wen

Re: [PATCH v2 19/34] drm/amd/display: decouple steps for mapping CRTC degamma to DC plane

On Fri, 25 Aug 2023 13:29:44 -0100 Melissa Wen wrote: > On 08/22, Pekka Paalanen wrote: > > On Thu, 10 Aug 2023 15:02:59 -0100 > > Melissa Wen wrote: > > > > > The next patch adds pre-blending degamma to AMD color mgmt pipeline, but > > > pre-blending

Re: [PATCH v7] drm/doc: Document DRM device reset expectations

non-robust >apps > > v5: > https://lore.kernel.org/dri-devel/20230627132323.115440-1-andrealm...@igalia.com/ > --- > Documentation/gpu/drm-uapi.rst | 77 ++++++ > 1 file changed, 77 insertions(+) Acked-by: Pekka Paalanen It's a good introduction, even

Re: [PATCH v2 31/34] drm/amd/display: set stream gamut remap matrix to MPC for DCN301

On Thu, 10 Aug 2023 15:03:11 -0100 Melissa Wen wrote: > dc->caps.color.mpc.gamut_remap says there is a post-blending color block > for gamut remap matrix for DCN3 HW family and newer versions. However, > those drivers still follow DCN10 programming that remap stream > gamut_remap_matrix to DPP

Re: [PATCH v2 08/34] drm/amd/display: document AMDGPU pre-defined transfer functions

On Thu, 10 Aug 2023 15:02:48 -0100 Melissa Wen wrote: > Brief documentation about pre-defined transfer function usage on AMD > display driver and standardized EOTFs and inverse EOTFs. > > Co-developed-by: Harry Wentland > Signed-off-by: Harry Wentland > Signed-off-by: Melissa Wen > --- >

Re: [PATCH v2 19/34] drm/amd/display: decouple steps for mapping CRTC degamma to DC plane

On Thu, 10 Aug 2023 15:02:59 -0100 Melissa Wen wrote: > The next patch adds pre-blending degamma to AMD color mgmt pipeline, but > pre-blending degamma caps (DPP) is currently in use to provide DRM CRTC > atomic degamma or implict degamma on legacy gamma. Detach degamma usage > regarging CRTC

Re: [PATCH v2 07/34] drm/amd/display: explicitly define EOTF and inverse EOTF

On Thu, 10 Aug 2023 15:02:47 -0100 Melissa Wen wrote: > Instead of relying on color block names to get the transfer function > intention regarding encoding pixel's luminance, define supported > Electro-Optical Transfer Functions (EOTFs) and inverse EOTFs, that > includes pure gamma or

Re: [PATCH v2 09/34] drm/amd/display: add plane HDR multiplier driver-specific property

On Thu, 10 Aug 2023 15:02:49 -0100 Melissa Wen wrote: > From: Joshua Ashton > > Multiplier to 'gain' the plane. When PQ is decoded using the fixed func > transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at > least) When sRGB is decoded, 1.0 -> 1.0. Therefore, 1.0 multiplier =

Re: [PATCH v5 6/6] drm/doc: Define KMS atomic state set

On Tue, 11 Jul 2023 10:57:57 +0200 Daniel Vetter wrote: > On Fri, Jul 07, 2023 at 07:40:59PM -0300, André Almeida wrote: > > From: Pekka Paalanen > > > > Specify how the atomic state is maintained between userspace and > > kernel, plus the special case for async

Re: [PATCH v5 6/6] drm/doc: Define KMS atomic state set

On Fri, 7 Jul 2023 19:40:59 -0300 André Almeida wrote: > From: Pekka Paalanen > > Specify how the atomic state is maintained between userspace and > kernel, plus the special case for async flips. > > Signed-off-by: Pekka Paalanen > Signed-off-by: André Almeida >

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

On Mon, 3 Jul 2023 12:00:22 -0300 André Almeida wrote: > Em 03/07/2023 05:49, Pekka Paalanen escreveu: > > If an application freezes, that's "no problem"; the end user can just > > continue using everything else. Alt-tab away etc. if the app was > > fullscree

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

On Mon, 3 Jul 2023 09:12:29 +0200 Michel Dänzer wrote: > On 6/30/23 22:32, Marek Olšák wrote: > > On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer > > wrote: > >> On 6/30/23 16:59, Alex Deucher wrote: > >>> On Fri, Jun 30, 2023 at 10:49 AM Sebastian Wick >

Re: [PATCH v4 6/6] drm/doc: Define KMS atomic state set

nges, not only the modesetting ones? Modesets are already gated by ALLOW_MODESET anyway. How about something like: An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is allowed to effectively change only the FB_ID property on any planes. No-operation changes are ignored as always. Changing any other

Re: [PATCH v4 1/1] drm/doc: Document DRM device reset expectations

> 1 file changed, 68 insertions(+) Hi, grammar nitpicks notwithstanding, I'm happy with the contents now, so Acked-by: Pekka Paalanen Thanks, pq > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 65fb3036a580..25a11b9b98fa 100644 > ---

Re: [RFC PATCH v3 2/4] drm: Create DRM_IOCTL_GET_RESET

On Wed, 21 Jun 2023 13:33:56 -0300 André Almeida wrote: > Em 21/06/2023 05:09, Pekka Paalanen escreveu: > > On Tue, 20 Jun 2023 21:57:17 -0300 > > André Almeida wrote: > > > >> Create a new DRM ioctl operation to get the numbers of resets for a > >>

Re: [RFC PATCH v3 1/4] drm/doc: Document DRM device reset expectations

On Wed, 21 Jun 2023 13:28:34 -0300 André Almeida wrote: > Em 21/06/2023 04:58, Pekka Paalanen escreveu: > > On Tue, 20 Jun 2023 21:57:16 -0300 > > André Almeida wrote: > > > >> Create a section that specifies how to deal with DRM device resets for >

Re: [RFC 0/9] drm: rcar-du: cmm: Enable 3D LUT support

On Wed, 21 Jun 2023 10:10:22 +0200 Jacopo Mondi wrote: > Hello, this series is based on the RFC sent by Melssa Wen: > "[RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface" > https://lore.kernel.org/dri-devel/20230109143846.1966301-1-m...@igalia.com/ > that introduces CRTC properties to control 3D

Re: [RFC PATCH v3 2/4] drm: Create DRM_IOCTL_GET_RESET

On Tue, 20 Jun 2023 21:57:17 -0300 André Almeida wrote: > Create a new DRM ioctl operation to get the numbers of resets for a > given context. The numbers reflect just the resets that happened after > the context was created, and not since the machine was booted. > > Create a debugfs interface

Re: [RFC PATCH v3 1/4] drm/doc: Document DRM device reset expectations

On Tue, 20 Jun 2023 21:57:16 -0300 André Almeida wrote: > Create a section that specifies how to deal with DRM device resets for > kernel and userspace drivers. > > Signed-off-by: André Almeida Hi André, nice to see this! I ended up giving lots of grammar comments, but I'm not a native

Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

On Thu, 15 Jun 2023 10:07:35 +0200 Jacopo Mondi wrote: > Hi Pekka > thanks for the reply > > On Thu, Jun 15, 2023 at 10:14:05AM +0300, Pekka Paalanen wrote: > > On Tue, 13 Jun 2023 17:43:55 +0200 > > Jacopo Mondi wrote: > > > > > Hello > > >

Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

On Tue, 13 Jun 2023 17:43:55 +0200 Jacopo Mondi wrote: > Hello > >I'm completing the support for 3D LUT on R-Car DU peripheral > and I have used this series as a base. > > I'm wondering, since quite some time has passed without any update if > this series is still a thing and it makes any

Re: [PATCH 00/36] drm/amd/display: add AMD driver-specific properties for color mgmt

On Tue, 30 May 2023 01:55:21 +0300 Dmitry Baryshkov wrote: > On 24/05/2023 01:14, Melissa Wen wrote: > > This series is a refined version of our RFC [1] for AMD driver-specific > > color management properties. It is a collection of contributions from > > Joshua, Harry and I to enhance AMD KMS

Re: [PATCH v4 00/13] Enable Colorspace connector property in amdgpu

On Thu, 25 May 2023 15:17:56 -0400 Harry Wentland wrote: > This patchset is based on Joshua's previous patchset [1], as well > as my previous patchset [2]. > > It is > - enabling support for the colorspace property in amdgpu, as well as > - allowing drivers to specify the supported set of

Re: [PATCH v4 02/13] drm/connector: Add enum documentation to drm_colorspace

C is "constant luminance" > - correct type for BT.601 > > v4: > - drop DP/HDMI clarifications that might create > more questions than answers > > Signed-off-by: Joshua Ashton > Signed-off-by: Harry Wentland > Reviewed-by: Harry Wentland > > Cc: Pekk

Re: [PATCH 06/36] drm/amd/display: add CRTC driver-specific property for gamma TF

On Tue, 23 May 2023 21:14:50 -0100 Melissa Wen wrote: > Hook up driver-specific atomic operations for managing AMD color > properties and create AMD driver-specific color management properties > and attach them according to HW capabilities defined by `struct > dc_color_caps`. Add enumerated

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

On Fri, 17 Mar 2023 16:14:38 +0200 Ville Syrjälä wrote: > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote: > > On Fri, 17 Mar 2023 14:50:40 +0200 > > Ville Syrjälä wrote: > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

On Fri, 17 Mar 2023 14:50:40 +0200 Ville Syrjälä wrote: > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > > On Fri, 17 Mar 2023 01:01:38 +0200 > > Ville Syrjälä wrote: > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

On Fri, 17 Mar 2023 01:01:38 +0200 Ville Syrjälä wrote: > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote: > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > wrote: > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

On Thu, 16 Mar 2023 12:47:51 +0200 Ville Syrjälä wrote: > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote: > > On Thu, 16 Mar 2023 11:50:27 +0200 > > Ville Syrjälä wrote: > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

ignalling? So if EDID says only one of them is supported, userspace should be confident that that is the BT2020 mode the driver will match? Thanks, pq > > > > > > Signed-off-by: Harry Wentland > > > Cc: Pekka Paalanen > > > Cc: Sebastian Wick > > &g

Re: [PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace

On Thu, 9 Mar 2023 01:56:11 +0100 Sebastian Wick wrote: > On Wed, Mar 8, 2023 at 9:59 AM Pekka Paalanen wrote: > > > > On Tue, 7 Mar 2023 10:10:52 -0500 > > Harry Wentland wrote: > > > > > From: Joshua Ashton > > > > > > To match the ot

Re: [PATCH v3 00/17] Enable Colorspace connector property in amdgpu

On Tue, 7 Mar 2023 10:10:50 -0500 Harry Wentland wrote: > This patchset is based on Joshua's previous patchset [1], as well > as my previous patchset [2]. > > It is > - enabling support for the colorspace property in amdgpu, as well as > - allowing drivers to specify the supported set of

Re: [PATCH v3 15/17] drm/amd/display: Add default case for output_color_space switch

On Tue, 7 Mar 2023 10:11:05 -0500 Harry Wentland wrote: > Signed-off-by: Harry Wentland > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Joshua Ashton > Cc: dri-de...@lists.freedesktop.org > Cc: amd-gfx@lists.freedesktop.org > Reviewed-By:

Re: [PATCH v3 14/17] drm/amd/display: Add debugfs for testing output colorspace

ndy when debugging display > issues. > > Signed-off-by: Harry Wentland > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Joshua Ashton > Cc: dri-de...@lists.freedesktop.org > Cc: amd-gfx@lists.freedesktop.org > Reviewed-By: J

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

On Tue, 7 Mar 2023 10:10:59 -0500 Harry Wentland wrote: > We want compositors to be able to set the output > colorspace on DP and HDMI outputs, based on the > caps reported from the receiver via EDID. > > Signed-off-by: Harry Wentland > Cc: Pekka Paalanen > Cc:

Re: [PATCH v3 06/17] drm/connector: Print connector colorspace in state debugfs

On Tue, 7 Mar 2023 10:10:56 -0500 Harry Wentland wrote: > v3: Fix kerneldocs (kernel test robot) > > Signed-off-by: Harry Wentland > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Uma Shankar > Cc: Ville Syrjälä > Cc: Joshua Ashton &

Re: [PATCH v3 05/17] drm/connector: Use common colorspace_names array

On Tue, 7 Mar 2023 10:10:55 -0500 Harry Wentland wrote: > We an use bitfields to track the support ones for HDMI > and DP. This allows us to print colorspaces in a consistent > manner without needing to know whether we're dealing with > DP or HDMI. > > Signed-off-by: Harry Wen

Re: [PATCH v3 03/17] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

t; - leave BT2020_RGB the new default BT2020 > > Signed-off-by: Joshua Ashton > Signed-off-by: Harry Wentland > Reviewed-by: Harry Wentland > > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Uma Shankar > Cc: Ville Syrjäl

Re: [PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace

hen I would prefer the documentation to spell out the unknowns and ambiguities. > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Uma Shankar > Cc: Ville Syrjälä > Cc: Joshua Ashton > Cc: dri-de...@lists.freedesktop.org > Cc

Re: [PATCH v4 01/17] drm/connector: Convert DRM_MODE_COLORIMETRY to enum

tland > Reviewed-by: Simon Ser > > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Uma Shankar > Cc: Ville Syrjälä > Cc: Joshua Ashton > Cc: dri-de...@lists.freedesktop.org > Cc: amd-gfx@lists.freedesktop.org > --- > includ

Re: [PATCH v2 1/1] drm/doc: Document DRM device reset expectations

On Tue, 28 Feb 2023 10:26:04 -0500 André Almeida wrote: > Hi Pekka, > > Thank you for your feedback, > > On 2/28/23 05:02, Pekka Paalanen wrote: > > On Mon, 27 Feb 2023 15:40:00 -0500 > > André Almeida wrote: > > > >> Create a section that sp

Re: [PATCH v2 1/1] drm/doc: Document DRM device reset expectations

On Mon, 27 Feb 2023 15:40:00 -0500 André Almeida wrote: > Create a section that specifies how to deal with DRM device resets for > kernel and userspace drivers. > > Signed-off-by: André Almeida > --- > Documentation/gpu/drm-uapi.rst | 51 ++ > 1 file changed,

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Tue, 14 Feb 2023 22:10:35 +0200 Ville Syrjälä wrote: > On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote: ... > > We also have to figure out how a user space which doesn't > > know about the new property behaves when another client has set that > > property. If any property

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Tue, 14 Feb 2023 15:04:52 -0500 Harry Wentland wrote: > On 2/14/23 14:45, Sebastian Wick wrote: > > On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland > > wrote: > >> > >> > >> > >> On 2/14/23 10:49, Sebastian Wick wrote: > >>> On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä > >>> wrote: >

Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

On Tue, 14 Feb 2023 11:19:47 +0200 Pekka Paalanen wrote: > On Mon, 13 Feb 2023 18:26:55 -0100 > Melissa Wen wrote: > > > On 02/10, Pekka Paalanen wrote: > > > On Thu, 9 Feb 2023 13:27:02 -0100 > > > Melissa Wen wrote: > > > > > > >

Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

On Mon, 13 Feb 2023 18:45:40 -0100 Melissa Wen wrote: > On 02/13, Ville Syrjälä wrote: > > On Mon, Feb 13, 2023 at 11:01:31AM +0200, Pekka Paalanen wrote: > > > On Fri, 10 Feb 2023 14:47:50 -0500 > > > Harry Wentland wrote: > > > > >

Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

On Mon, 13 Feb 2023 18:26:55 -0100 Melissa Wen wrote: > On 02/10, Pekka Paalanen wrote: > > On Thu, 9 Feb 2023 13:27:02 -0100 > > Melissa Wen wrote: > > > > > On 01/31, Pekka Paalanen wrote: > > > > On Mon, 9 Jan 2023 14:38:09 -0100 > > >

Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

On Fri, 10 Feb 2023 14:47:50 -0500 Harry Wentland wrote: > On 2/10/23 04:28, Pekka Paalanen wrote: > > On Thu, 9 Feb 2023 13:27:02 -0100 > > Melissa Wen wrote: > > > >> On 01/31, Pekka Paalanen wrote: > >>> On Mon, 9 Jan 2023 14:38:09 -0100 > &g

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Thu, 09 Feb 2023 17:03:19 + Simon Ser wrote: > On Thursday, February 9th, 2023 at 17:38, Joshua Ashton > wrote: > > > > I mean, the strings are the uAPI, not the integers, right? > > > > Both are uAPI these days. > > Yes. The integers are uAPI, if you change them you'll break

Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

On Thu, 9 Feb 2023 13:27:02 -0100 Melissa Wen wrote: > On 01/31, Pekka Paalanen wrote: > > On Mon, 9 Jan 2023 14:38:09 -0100 > > Melissa Wen wrote: > > > > > On 01/09, Melissa Wen wrote: > > > > Hi, > > > > > > > > After

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Wed, 8 Feb 2023 16:49:31 +0200 Ville Syrjälä wrote: > On Wed, Feb 08, 2023 at 11:18:42AM +0200, Pekka Paalanen wrote: > > On Fri, 3 Feb 2023 16:02:51 +0200 > > Ville Syrjälä wrote: > > > > > On Fri, Feb 03, 2023 at 02:52:50PM +0100, Sebastian Wick wrote: &g

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Mon, 6 Feb 2023 12:16:28 -0500 Harry Wentland wrote: > On 2/6/23 04:47, Ville Syrjälä wrote: > > On Sat, Feb 04, 2023 at 06:09:45AM +, Joshua Ashton wrote: > >> > >> > >> On 2/3/23 19:34, Ville Syrjälä wrote: > >>> On Fri, Feb 03, 2023 at 09:25:38PM +0200, Ville Syrjälä wrote: >

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Fri, 3 Feb 2023 14:33:46 -0500 Harry Wentland wrote: > On 2/3/23 14:25, Ville Syrjälä wrote: > > On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote: > >> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote: > >>> > >>> > >>> On 2/3/23 11:00, Ville Syrjälä wrote: >

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

ible to be taken advantage of anyway, as there is currently no > pixel_encoding control so it would not be possible to output > linear YCbCr. > > Signed-off-by: Joshua Ashton > > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Uma Shankar > Cc: Ville S

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Fri, 3 Feb 2023 20:56:55 +0200 Ville Syrjälä wrote: > Anyways, sounds like what you're basically proposing is > getting rid of this property and starting from scratch. I would be happy with that (throwing "Colorspace" out and defining something new). Then we can start with enum values we

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Fri, 3 Feb 2023 18:00:44 +0200 Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > > > > > > On 2/3/23 10:19, Ville Syrjälä wrote: > > > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > >> > > >> > > >> On 2/3/23 07:59, Sebastian

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Fri, 3 Feb 2023 16:02:51 +0200 Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 02:52:50PM +0100, Sebastian Wick wrote: > > On Fri, Feb 3, 2023 at 2:35 PM Ville Syrjälä > > wrote: > > > > > > On Fri, Feb 03, 2023 at 01:59:07PM +0100, Sebastian Wick wrote: > > > > On Fri, Feb 3, 2023 at

Re: [PATCH 2/3] drm/connector: Add enum documentation to drm_colorspace

On Fri, 3 Feb 2023 02:07:43 + Joshua Ashton wrote: > To match the other enums, and add more information about these values. > > Signed-off-by: Joshua Ashton > > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Uma Shankar > Cc:

Re: [PATCH 1/3] drm/connector: Convert DRM_MODE_COLORIMETRY to enum

On Fri, 3 Feb 2023 02:07:42 + Joshua Ashton wrote: > From: Harry Wentland > > This allows us to use strongly typed arguments. > > Signed-off-by: Harry Wentland > Reviewed-by: Simon Ser > > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@a

Re: [RFC PATCH] drm: Create documentation about device resets

On Mon, 23 Jan 2023 21:38:11 +0100 Christian König wrote: > Am 23.01.23 um 21:26 schrieb André Almeida: > > Create a document that specifies how to deal with DRM device resets for > > kernel and userspace drivers. > > > > Signed-off-by: André Almeida > > --- > >

Re: [PATCH v2 00/21] Enable Colorspace connector property in amdgpu

ot;RGB" would imply anything about colorimetry when it's just a color model. Sometimes it might not be sRGB because the "default RGB" has probably not been sRGB for many years now, depending on monitor settings. See also https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/1

Re: [PATCH v2 18/21] drm/amd/display: Fallback to 2020_YCBCR if the pixel encoding is not RGB

requested but the output encoding is YCbCr we should > >> send COLOR_SPACE_2020_YCBCR. > >> > >> Signed-off-by: Joshua Ashton > >> Signed-off-by: Harry Wentland > >> Cc: Pekka Paalanen > >> Cc: Sebastian Wick > >> Cc: vitaly.pros...@a

  1   2   3   >