Re: [PATCH v2 4/6] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits

On Tue, 30 Aug 2022 17:29:35 + Simon Ser wrote: > If the driver supports it, allow user-space to supply the > DRM_MODE_PAGE_FLIP_ASYNC flag to request an async page-flip. > Set drm_crtc_state.async_flip accordingly. > > Document that drivers will reject atomic commits if an async > flip isn'

KMS atomic state sets, full vs. minimal (Re: [PATCH v3 0/6] Add support for atomic async page-flips)

On Fri, 30 Sep 2022 18:09:55 +0300 Ville Syrjälä wrote: > That would actively discourage people from even attempting the > "just dump all the state into the ioctl" approach with async flips > since even the props whose value isn't even changing would be rejected. About that. To me it looks like

Re: KMS atomic state sets, full vs. minimal (Re: [PATCH v3 0/6] Add support for atomic async page-flips)

On Fri, 30 Sep 2022 18:45:09 +0300 Ville Syrjälä wrote: > On Fri, Sep 30, 2022 at 06:37:00PM +0300, Pekka Paalanen wrote: > > On Fri, 30 Sep 2022 18:09:55 +0300 > > Ville Syrjälä wrote: > > > > > That would actively discourage people from even attempting the

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Thu, 10 Mar 2022 11:56:41 -0800 Rob Clark wrote: > For something like just notifying a compositor that a gpu crash > happened, perhaps drm_event is more suitable. See > virtio_gpu_fence_event_create() for an example of adding new event > types. Although maybe you want it to be an event which

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Mon, 14 Mar 2022 10:23:27 -0400 Alex Deucher wrote: > On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen wrote: > > > > On Thu, 10 Mar 2022 11:56:41 -0800 > > Rob Clark wrote: > > > > > For something like just notifying a compositor that a gpu crash >

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Tue, 15 Mar 2022 10:54:38 -0400 Alex Deucher wrote: > On Mon, Mar 14, 2022 at 11:26 AM Pekka Paalanen wrote: > > > > On Mon, 14 Mar 2022 10:23:27 -0400 > > Alex Deucher wrote: > > > > > On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen > > > wr

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

RGB_FULLRANGE is > >> 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 >

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

uot;RGB". I find that very confusing that "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 htt

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 > > --- > > Documentation/gpu/drm-reset.rst

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: [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 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 11:4

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 Wi

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 care

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

ssible 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 &

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

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 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: [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 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 libli

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: [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 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 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: [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: [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 whic

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, 51

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 specif

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

Harry Wentland > 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 > --- &g

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 v3 03/17] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

se > - 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 S

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: Harr

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 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 14/17] drm/amd/display: Add debugfs for testing output colorspace

in handy 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-

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 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 colorsp

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 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

s RGB or YCbCr signalling? 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: Sebastia

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

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 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 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 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 trans

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 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 colors

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 col

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 s

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 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 speake

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 t

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 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 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: [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: [PATCH v3 0/2] drm: Add GPU reset sysfs

On Fri, 25 Nov 2022 14:52:01 -0300 André Almeida wrote: > This patchset adds a udev event for DRM device's resets. Hi, this seems a good idea to me. > Userspace apps can trigger GPU resets by misuse of graphical APIs or driver > bugs. Either way, the GPU reset might lead the system to a broken

Re: [PATCH v3 1/2] drm: Add GPU reset sysfs event

On Fri, 25 Nov 2022 14:52:02 -0300 André Almeida wrote: > From: Shashank Sharma > > Add a sysfs event to notify userspace about GPU resets providing: > - PID that triggered the GPU reset, if any. Resets can happen from > kernel threads as well, in that case no PID is provided > - Information

Re: [PATCH 06/16] drm/connector: Allow drivers to pass list of supported colorspaces

, where for each enum drm_colorspace entry has a row explaining: Thanks, pq > 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 > Cc: dri-de...@lists.freedesk

Re: [PATCH 06/16] drm/connector: Allow drivers to pass list of supported colorspaces

t from Wikipedia or whatever which is annoying and raises questions about its correctness. Would be better if someone who actually has access to the authoritative specs would review the table. Thanks, pq > Signed-off-by: Harry Wentland > Cc: Pekka Paalanen > Cc: Sebastian Wick >

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

in handy when debugging display > issues. > > 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 > Cc: dri-de...@lists.freedesktop.org > Cc: amd-gfx@

Re: [PATCH 04/16] drm/connector: Convert DRM_MODE_COLORIMETRY to enum

On Mon, 12 Dec 2022 13:21:25 -0500 Harry Wentland wrote: > This allows us to use strongly typed arguments. > > Signed-off-by: Harry Wentland > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Uma Shankar > Cc: Ville Syrjälä > Cc:

Re: [PATCH 16/16] drm/amd/display: Don't restrict bpc to 8 bpc

If this somehow turns out to still be an issue I > suggest we add a module parameter to allow users to > limit the max_bpc to a desired value. > > Signed-off-by: Harry Wentland > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com >

Re: [PATCH 06/16] drm/connector: Allow drivers to pass list of supported colorspaces

On Tue, 13 Dec 2022 11:32:01 -0500 Harry Wentland wrote: > On 12/13/22 05:23, Pekka Paalanen wrote: > > On Mon, 12 Dec 2022 13:21:27 -0500 > > Harry Wentland wrote: > > > >> Drivers might not support all colorspaces defined in > >> dp_colorspace

Re: [PATCH 04/16] drm/connector: Convert DRM_MODE_COLORIMETRY to enum

On Tue, 13 Dec 2022 11:41:08 -0500 Harry Wentland wrote: > On 12/13/22 05:39, Pekka Paalanen wrote: > > On Mon, 12 Dec 2022 13:21:25 -0500 > > Harry Wentland wrote: > > > >> This allows us to use strongly typed arguments. > >> > >> Signed

Re: [PATCH 16/16] drm/amd/display: Don't restrict bpc to 8 bpc

On Tue, 13 Dec 2022 18:20:59 +0100 Michel Dänzer wrote: > On 12/12/22 19:21, Harry Wentland wrote: > > This will let us pass kms_hdr.bpc_switch. > > > > I don't see any good reasons why we still need to > > limit bpc to 8 bpc and doing so is problematic when > > we enable HDR. > > > > If I reme

Re: [PATCH 16/16] drm/amd/display: Don't restrict bpc to 8 bpc

On Wed, 14 Dec 2022 10:46:55 -0500 Alex Deucher wrote: > On Wed, Dec 14, 2022 at 4:01 AM Pekka Paalanen wrote: > > > > On Tue, 13 Dec 2022 18:20:59 +0100 > > Michel Dänzer wrote: > > > > > On 12/12/22 19:21, Harry Wentland wrote: > > &g

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

md-gfx/20220619223104.667413-1-m...@igalia.com/ > > [4] > > https://lore.kernel.org/dri-devel/20221004211451.1475215-1-alex.h...@amd.com/ > > [5] https://patchwork.freedesktop.org/series/90165/ > > [6] https://patchwork.freedesktop.org/series/109402/ > > [VA_API] > >

Re: [PATCH] drm: Don't block HDR_OUTPUT_METADATA on unknown EOTF

an compositor can immediately make use of it. > > Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/609 > > Signed-off-by: Harry Wentland > Cc: ppaala...@gmail.com > Cc: sebastian.w...@redhat.com > Cc: vpros...@amd.com > Cc: Uma Shankar Acked-by: Pekka Paalanen Thanks,

Re: [PATCH 2/3] Documentation/gpu: Add an explanation about the DCN pipeline

adding a new section that describes what a pipeline is from the DCN > perspective. > > Cc: Harry Wentland > Cc: Nicholas Kazlauskas > Cc: Bhawanpreet Lakha > Cc: Hersen Wu > Cc: Alex Hung > Cc: Pierre-Eric Pelloux-Prayer > Cc: Leo Li > Cc: Simon Ser > Cc: Pekka

Re: [PATCH 2/3] Documentation/gpu: Add an explanation about the DCN pipeline

On Thu, 16 Jun 2022 17:59:21 -0400 Rodrigo Siqueira Jordao wrote: > On 2022-06-15 07:12, Pekka Paalanen wrote: > > On Mon, 13 Jun 2022 16:01:11 -0400 > > Rodrigo Siqueira wrote: > > > >> In the DCN code, we constantly talk about hardware pipeline, pipeline, >

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

inds of other-than-FB changes, 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 a

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 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 > > fullscr

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 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 fl

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 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 standardize

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 col

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 (p

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 v7] drm/doc: Document DRM device reset expectations

bout 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

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

? Does 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 > > Meliss

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

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 v2 2/3] drm: Add variable refresh property to DRM CRTC

Hi, I have a somewhat of my own view on what would be involved with VRR, and I'd like to hear what you think of it. Comments inline. On Tue, 25 Sep 2018 09:51:37 -0400 "Kazlauskas, Nicholas" wrote: > On 09/24/2018 04:26 PM, Ville Syrjälä wrote: > > On Mon, Sep 24, 2018 at 03:06:02PM -0400, Kaz

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On Fri, 5 Oct 2018 12:21:20 -0400 "Kazlauskas, Nicholas" wrote: > On 10/05/2018 04:10 AM, Pekka Paalanen wrote: > > Hi, > > > > I have a somewhat of my own view on what would be involved with VRR, > > and I'd like to hear what you think of it. Comments

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On Wed, 10 Oct 2018 09:35:50 -0400 "Kazlauskas, Nicholas" wrote: > The patches I've put out target this use case mostly because of the > benefit for a relatively simple interface. VRR can and has been used in > more ways that this, however. > > An example usecase that differs from this would a

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On Fri, 12 Oct 2018 07:35:57 + "Koenig, Christian" wrote: > Am 12.10.2018 um 09:23 schrieb Pekka Paalanen: > > On Wed, 10 Oct 2018 09:35:50 -0400 > > "Kazlauskas, Nicholas" wrote: > > > >> The patches I've put out target this use c

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On Fri, 12 Oct 2018 08:58:23 -0400 "Kazlauskas, Nicholas" wrote: > On 10/12/2018 07:20 AM, Koenig, Christian wrote: > > Am 12.10.2018 um 11:21 schrieb Pekka Paalanen: > >> On Fri, 12 Oct 2018 07:35:57 + > >> "Koenig, Christian" wrote: &g

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On Mon, 15 Oct 2018 12:02:14 -0400 "Kazlauskas, Nicholas" wrote: > On 10/15/2018 09:57 AM, Pekka Paalanen wrote: > > On Fri, 12 Oct 2018 08:58:23 -0400 > > "Kazlauskas, Nicholas" wrote: > > > >> On 10/12/2018 07:20 AM, Koenig, Christian w

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On Thu, 11 Oct 2018 12:39:41 -0400 Nicholas Kazlauskas wrote: > These include the drm_connector 'vrr_capable' and the drm_crtc > 'vrr_enabled' properties. > > Signed-off-by: Nicholas Kazlauskas > --- > Documentation/gpu/drm-kms.rst | 7 +++ > drivers/gpu/drm/drm_connector.c | 22 +++

Re: [PATCH v5 2/4] drm: Add vrr_enabled property to drm CRTC

On Mon, 15 Oct 2018 12:06:52 +0200 Michel Dänzer wrote: > On 2018-10-15 11:47 a.m., Christian König wrote: > > Am 15.10.2018 um 11:40 schrieb Michel Dänzer: > >> On 2018-10-13 7:38 p.m., Christian König wrote: > >>> Am 12.10.2018 um 18:44 schrieb Nicholas Kazlauskas: > This patch intro

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On Fri, 26 Oct 2018 17:34:15 + "Kazlauskas, Nicholas" wrote: > On 10/26/18 10:53 AM, Ville Syrjälä wrote: > > On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote: > >> On 10/26/18 7:37 AM, Pekka Paalanen wrote: > >>> Hi, >

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On Wed, 31 Oct 2018 17:54:34 + "Kazlauskas, Nicholas" wrote: > On 10/31/18 12:20 PM, Michel Dänzer wrote: > > On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote: > >> On 10/31/18 10:12 AM, Michel Dänzer wrote: > >>> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote: > On 10/30/1

Re: [PATCH v6 3/5] drm: Document variable refresh properties

gt; >> 'vrr_enabled' properties. > >> > >> Signed-off-by: Nicholas Kazlauskas > >> Cc: Harry Wentland > >> Cc: Manasi Navare > >> Cc: Pekka Paalanen > >> Cc: Ville Syrjälä > >> Cc: Michel Dänzer > >> ---

Re: [PATCH 0/6] RFC Support hot device unplug in amdgpu

On Sat, 9 May 2020 14:51:44 -0400 Andrey Grodzovsky wrote: > This RFC is a more of a proof of concept then a fully working > solution as there are a few unresolved issues we are hopping to get > advise on from people on the mailing list. Until now extracting a > card either by physical extraction

Re: [PATCH] drm: add drm device name

On Tue, 17 Sep 2019 13:32:05 +0200 Daniel Vetter wrote: > On Tue, Sep 17, 2019 at 11:27 AM Michel Dänzer wrote: > > > > On 2019-09-17 11:23 a.m., Michel Dänzer wrote: > > > On 2019-09-17 10:23 a.m., Koenig, Christian wrote: > > >> Am 17.09.19 um 10:17 schrieb Daniel Vetter: > > >>> On Tue,

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 12:12:01 +0200 Gerd Hoffmann wrote: > Ok, this is really a kickstart for a discussion. While working on > graphics support for virtual machines on ppc64 (which exists in both > little and big endian variants) I've figured the comments in the header > file don't match reality.

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 16:17:27 +0200 Gerd Hoffmann wrote: > Hi, > > > which software have you used as representative of "reality"? > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and > only form

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 12:10:14 -0400 Ilia Mirkin wrote: > On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote: > > I also wonder if a real BE machine could have different results than > > the virtual machine. > > I have a PPC G5 with an AGP GeForce FX 5200 that I can

<    1   2   3   >