Re: [PATCH 6/6] drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2

On Tue, 16 Aug 2016 10:46:13 +0900 Michel Dänzer <mic...@daenzer.net> wrote: > On 16/08/16 10:32 AM, Mario Kleiner wrote: > > Cc'ing Daniel Stone and Pekka Paalanen, because this relates to wayland. > > > > Wrt. having a new pageflip parameter struct, i wonder if

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 <imir...@alum.mit.edu> wrote: > On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > > I also wonder if a real BE machine could have different results than > > the virtual machine. >

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

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

yuv formats as-is. I have no idea if and how those are used > on bigendian machines. > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> > Cc: Daniel Vetter <daniel.vet...@intel.com> > Cc: Pekka Paalanen <ppaala...@gmail.com> > Cc: Ilia Mirkin <i

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

On Fri, 21 Apr 2017 14:08:04 +0300 Ville Syrjälä wrote: > On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: > > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > > > >

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

On Tue, 11 Apr 2017 13:23:53 +0200 Gerd Hoffmann wrote: > Hi, > > > > Just let know what you need tested, I should be able to turn it around > > > within a couple of days. > > > > That's part of my problem. I don't really know what should be tested. > > What do people do

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

On Tue, 18 Apr 2017 15:39:53 +0200 Gerd Hoffmann wrote: > Hi, > > > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest > > > here, it drives the qemu stdvga with offb, not bochs-drm. > > > > I suppose this proves the virtual machine itself is

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

On Tue, 18 Apr 2017 12:00:17 +0200 Gerd Hoffmann wrote: > Hi, > > > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > > > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and > > > only format supported by bochs-drm), and we

Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN

On Tue, 2 May 2017 14:53:43 +0100 Emil Velikov wrote: > Hi Gerd, > > I did not have the change to follow through the discussion. > Pardon if my suggestion have already been discussed. > > On 2 May 2017 at 14:34, Gerd Hoffmann wrote: > > It's

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 case m

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

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

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

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,

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 inli

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

t; '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 > >> --- > >> Docu

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

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

Re: [PATCH] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is

On Tue, 25 Aug 2020 12:58:19 -0400 "Kazlauskas, Nicholas" wrote: > On 2020-08-22 5:59 a.m., Michel Dänzer wrote: > > On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote: > >> On 2020-08-21 12:57 p.m., Michel Dänzer wrote: > >>> From: Michel Dänzer > >>> > >>> Don't check

Re: [PATCH] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is

On Sat, 22 Aug 2020 11:59:26 +0200 Michel Dänzer wrote: > On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote: > > On 2020-08-21 12:57 p.m., Michel Dänzer wrote: > >> From: Michel Dänzer > >> > >> Don't check drm_crtc_state::active for this either, per its > >> documentation in

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

On Mon, 22 Jun 2020 11:35:01 +0200 Daniel Vetter wrote: > On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote: > > Will be used to reroute CPU mapped BO's page faults once > > device is removed. > > > > Signed-off-by: Andrey Grodzovsky > > --- > > drivers/gpu/drm/drm_file.c |

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

On Mon, 22 Jun 2020 16:24:38 +0200 Daniel Vetter wrote: > On Mon, Jun 22, 2020 at 4:22 PM Pekka Paalanen wrote: > > > > On Mon, 22 Jun 2020 11:35:01 +0200 > > Daniel Vetter wrote: > > > > > On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrot

Re: [PATCH v2 0/3] Experimental freesync video mode optimization

On Mon, 14 Dec 2020 21:57:25 +0100 Christian König wrote: > Am 11.12.20 um 13:20 schrieb Pekka Paalanen: > > On Fri, 11 Dec 2020 11:28:36 +0100 > > Christian König wrote: > > > >> Am 11.12.20 um 10:55 schrieb Pekka Paalanen: > >>> On Fri, 11 Dec

Re: [PATCH v2 0/3] Experimental freesync video mode optimization

On Fri, 11 Dec 2020 09:56:07 +0530 Shashank Sharma wrote: > Hello Simon, > > Hope you are doing well, > > I was helping out Aurabindo and the team with the design, so I have > taken the liberty of adding some comments on behalf of the team, > Inline. > > On 11/12/20 3:31 am, Simon Ser wrote:

Re: [PATCH v2 0/3] Experimental freesync video mode optimization

On Fri, 11 Dec 2020 11:28:36 +0100 Christian König wrote: > Am 11.12.20 um 10:55 schrieb Pekka Paalanen: > > On Fri, 11 Dec 2020 09:56:07 +0530 > > Shashank Sharma wrote: > > > >> Hello Simon, > >> > >> Hope you are doing well, &g

Re: [PATCH v3 1/3] drm/amd/display: Add module parameter for freesync video mode

On Mon, 4 Jan 2021 16:07:58 -0500 Aurabindo Pillai wrote: > [Why] > Adds a module parameter to enable experimental freesync video mode modeset > optimization. Enabling this mode allows the driver to skip a full modeset when > freesync compatible modes are requested by the userspace. This

Re: [PATCH 0/3] Experimental freesync video mode optimization

On Tue, 19 Jan 2021 10:50:26 -0500 Aurabindo Pillai wrote: > Changes in V5 > = > > * More info in commit messages on the rationale of changes being added > to the kernel. > * Minor fixes Hi, thank you for adding the explanations in the commit messages I asked for. It is now up to

Re: [PATCH v3 1/3] drm/amd/display: Add module parameter for freesync video mode

On Mon, 18 Jan 2021 09:36:47 -0500 Aurabindo Pillai wrote: > On Thu, 2021-01-14 at 11:14 +0200, Pekka Paalanen wrote: > > > > Hi, > > > > please document somewhere that ends up in git history (commit > > message, > > code comments, description of the pa

Re: [PATCH v2 1/7] drm/sysfs: introduce drm_sysfs_connector_hotplug_event

On Wed, 09 Jun 2021 21:23:27 + Simon Ser wrote: > This function sends a hotplug uevent with a CONNECTOR property. > > Signed-off-by: Simon Ser > --- > drivers/gpu/drm/drm_sysfs.c | 25 + > include/drm/drm_sysfs.h | 1 + > 2 files changed, 26 insertions(+) > >

Re: [PATCH v2 5/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

On Tue, 8 Jun 2021 19:43:18 +0200 Werner Sembach wrote: > Add a new general drm property "active color format" which can be used by > graphic drivers to report the used color format back to userspace. > > There was no way to check which color format got actually used on a given > monitor. To

Re: [PATCH v2 2/7] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

On Tue, 8 Jun 2021 19:43:15 +0200 Werner Sembach wrote: > Add a new general drm property "active bpc" which can be used by graphic > drivers > to report the applied bit depth per pixel back to userspace. > > While "max bpc" can be used to change the color depth, there was no way to > check >

Re: New uAPI for color management proposal and feedback request

On Tue, 22 Jun 2021 19:06:43 +0200 Werner Sembach wrote: > Am 19.05.21 um 11:34 schrieb Pekka Paalanen: > > On Wed, 12 May 2021 16:04:16 +0300 > > Ville Syrjälä wrote: > > > >> On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: > &

Re: [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context

On Tue, 22 Jun 2021 11:57:53 +0200 Werner Sembach wrote: > Am 22.06.21 um 09:25 schrieb Pekka Paalanen: > > On Fri, 18 Jun 2021 11:11:14 +0200 > > Werner Sembach wrote: > > > >> Add "Broadcast RGB" to general drm context so that more drivers be

Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

On Tue, 22 Jun 2021 11:48:52 + Simon Ser wrote: > On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach > wrote: > > > Unknown is when no monitor is connected or is when the > > connector/monitor is disabled. > > I think the other connector props (link-status, non-desktop, etc) don't >

Re: [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property

On Tue, 22 Jun 2021 11:28:57 +0200 Werner Sembach wrote: > Am 22.06.21 um 09:29 schrieb Pekka Paalanen: > > On Fri, 18 Jun 2021 11:11:16 +0200 > > Werner Sembach wrote: > > > >> This commit implements the "Broadcast RGB" drm property for the A

Re: [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context

On Wed, 23 Jun 2021 12:10:14 +0200 Werner Sembach wrote: > Am 23.06.21 um 09:48 schrieb Pekka Paalanen: > > On Tue, 22 Jun 2021 11:57:53 +0200 > > Werner Sembach wrote: > > > >> Am 22.06.21 um 09:25 schrieb Pekka Paalanen: > >>> On Fri, 18 Jun 2021

Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

On Wed, 23 Jun 2021 12:17:40 +0200 Werner Sembach wrote: > Am 23.06.21 um 09:32 schrieb Pekka Paalanen: > > On Tue, 22 Jun 2021 11:48:52 + > > Simon Ser wrote: > > > >> On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach > >> wrote: > >>

Re: [PATCH v4 06/17] drm/uAPI: Add "active color format" drm property as feedback for userspace

int min, int max); > int drm_connector_attach_active_bpc_property(struct drm_connector > *connector, int min, int max); > void drm_connector_set_active_bpc_property(struct drm_connector *connector, > int active_bpc); > +int drm_connector_attach_active_color_format_property(struct drm_connector > *connector); > +void drm_connector_set_active_color_format_property(struct drm_connector > *connector, > + u32 active_color_format); > > /** > * struct drm_tile_group - Tile group metadata Acked-by: Pekka Paalanen Thanks, pq pgp3l7sh_cavZ.pgp Description: OpenPGP digital signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

ine DRM_CONNECTOR_POLL_HPD (1 << 0) > #define DRM_CONNECTOR_POLL_CONNECT (1 << 1) > #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2) > @@ -1702,6 +1708,8 @@ int drm_connector_set_panel_orientation_with_quirk( > int width, int height); > int drm_connector_attach_max_b

Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

rty. > + */ > + u32 preferred_color_format; Hi, yes, I think this makes sense, even if it is a property that one can't tell for sure what it does before hand. Using a pair of properties, preference and active, to ask for something and then check what actually worked is good

Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

On Fri, 18 Jun 2021 11:11:08 +0200 Werner Sembach wrote: > Add a new general drm property "active color range" which can be used by > graphic drivers to report the used color range back to userspace. > > There was no way to check which color range got actually used on a given > monitor. To

Re: [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context

On Fri, 18 Jun 2021 11:11:14 +0200 Werner Sembach wrote: > Add "Broadcast RGB" to general drm context so that more drivers besides > i915 and gma500 can implement it without duplicating code. > > Userspace can use this property to tell the graphic driver to use full or > limited color range for

Re: [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property

On Fri, 18 Jun 2021 11:11:16 +0200 Werner Sembach wrote: > This commit implements the "Broadcast RGB" drm property for the AMD GPU > driver. > > Signed-off-by: Werner Sembach > --- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++- >

Re: [PATCH] drm/amd/display: Expose active display color configurations to userspace

On Tue, 11 May 2021 12:03:30 +0200 Werner Sembach wrote: > Am 11.05.21 um 10:07 schrieb Pekka Paalanen: > > On Mon, 10 May 2021 17:47:01 -0400 > > Alex Deucher wrote: > > > >> On Fri, May 7, 2021 at 3:27 PM Werner Sembach > >> wrote: > >>>

Re: [PATCH] drm/amd/display: Expose active display color configurations to userspace

On Mon, 10 May 2021 17:47:01 -0400 Alex Deucher wrote: > On Fri, May 7, 2021 at 3:27 PM Werner Sembach > wrote: > > > > xrandr --prop and other userspace info tools have currently no way of > > telling which color configuration is used on HDMI and DP ports. > > > > The ongoing transsition from

Re: [RFC PATCH 1/3] drm/color: Add RGB Color encodings

On Fri, 14 May 2021 17:04:51 -0400 Harry Wentland wrote: > On 2021-04-30 8:53 p.m., Sebastian Wick wrote: > > On 2021-04-26 20:56, Harry Wentland wrote: ... > >> Another reason I'm proposing to define the color space (and gamma) of > >> a plane is to make this explicit. Up until the color

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On Fri, 14 May 2021 17:05:11 -0400 Harry Wentland wrote: > On 2021-04-27 10:50 a.m., Pekka Paalanen wrote: > > On Mon, 26 Apr 2021 13:38:49 -0400 > > Harry Wentland wrote: ... > >> ## Mastering Luminances > >> > >> Now we are able to use the PQ 2084 E

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On Mon, 17 May 2021 15:39:03 -0400 Vitaly Prosyak wrote: > On 2021-05-17 12:48 p.m., Sebastian Wick wrote: > > On 2021-05-17 10:57, Pekka Paalanen wrote: > >> On Fri, 14 May 2021 17:05:11 -0400 > >> Harry Wentland wrote: > >> > >>>

Re: [RFC PATCH v2 0/6] A drm_plane API to support HDR planes

On Fri, 14 May 2021 17:07:14 -0400 Harry Wentland wrote: > We are looking to enable HDR support for a couple of single-plane and > multi-plane scenarios. To do this effectively we recommend new interfaces > to drm_plane. The first patch gives a bit of background on HDR and why we > propose these

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On Wed, 19 May 2021 11:53:37 +0300 Pekka Paalanen wrote: ... > TL;DR: > > I would summarise my comments so far into these: > > - Telling the kernel the color spaces and letting it come up with > whatever color transformation formula from those is not enough, > becau

Re: [RFC PATCH 1/3] drm/color: Add RGB Color encodings

On Tue, 18 May 2021 10:32:48 -0400 Harry Wentland wrote: > On 2021-05-17 4:34 a.m., Pekka Paalanen wrote: > > On Fri, 14 May 2021 17:04:51 -0400 > > Harry Wentland wrote: > > > >> On 2021-04-30 8:53 p.m., Sebastian Wick wrote: > >>>

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On Tue, 18 May 2021 10:19:25 -0400 Harry Wentland wrote: > On 2021-05-18 3:56 a.m., Pekka Paalanen wrote: > > On Mon, 17 May 2021 15:39:03 -0400 > > Vitaly Prosyak wrote: > > > >> On 2021-05-17 12:48 p.m., Sebastian Wick wrote: ... > >>> I s

Re: New uAPI for color management proposal and feedback request

On Wed, 19 May 2021 16:49:35 +0300 Ville Syrjälä wrote: > On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote: > > On Wed, 12 May 2021 16:04:16 +0300 > > Ville Syrjälä wrote: > > > > > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner

Re: [PATCH 2/4] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

On Fri, 4 Jun 2021 19:17:21 +0200 Werner Sembach wrote: > Add a new general drm property "active bpc" which can be used by graphic > drivers > to report the applied bit depth per pixel back to userspace. > > While "max bpc" can be used to change the color depth, there was no way to > check >

Re: New uAPI for color management proposal and feedback request

On Mon, 7 Jun 2021 09:48:05 +0200 Maxime Ripard wrote: > I've started to implement this for the raspberrypi some time ago. > > https://github.com/raspberrypi/linux/pull/4201 > > It's basically two properties: a bitmask of the available output pixel > encoding to report both what the display

Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

On Wed, 30 Jun 2021 11:20:18 +0200 Werner Sembach wrote: > Am 30.06.21 um 10:41 schrieb Pekka Paalanen: > > > On Tue, 29 Jun 2021 13:39:18 +0200 > > Werner Sembach wrote: > > > >> Am 29.06.21 um 13:17 schrieb Pekka Paalanen: > >>> On Tue, 29 J

Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

On Wed, 30 Jun 2021 11:42:10 +0200 Werner Sembach wrote: > Am 30.06.21 um 10:21 schrieb Pekka Paalanen: > > On Tue, 29 Jun 2021 13:02:05 +0200 > > Werner Sembach wrote: > > > >> Am 28.06.21 um 19:03 schrieb Werner Sembach: > >>> Am 18.06.21 um

Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

On Tue, 29 Jun 2021 13:02:05 +0200 Werner Sembach wrote: > Am 28.06.21 um 19:03 schrieb Werner Sembach: > > Am 18.06.21 um 11:11 schrieb Werner Sembach: > >> Add a new general drm property "active bpc" which can be used by graphic > >> drivers to report the applied bit depth per pixel back to

Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

On Tue, 29 Jun 2021 13:39:18 +0200 Werner Sembach wrote: > Am 29.06.21 um 13:17 schrieb Pekka Paalanen: > > On Tue, 29 Jun 2021 08:12:54 + > > Simon Ser wrote: > > > >> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen > >> wrote: > >

Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

On Thu, 1 Jul 2021 14:50:13 +0200 Werner Sembach wrote: > Am 01.07.21 um 10:07 schrieb Pekka Paalanen: > > > On Wed, 30 Jun 2021 11:20:18 +0200 > > Werner Sembach wrote: > > > >> Am 30.06.21 um 10:41 schrieb Pekka Paalanen: > >> > >>> O

Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

On Mon, 5 Jul 2021 17:49:42 +0200 Werner Sembach wrote: > Am 01.07.21 um 15:24 schrieb Pekka Paalanen: > > On Thu, 1 Jul 2021 14:50:13 +0200 > > Werner Sembach wrote: > > > >> Am 01.07.21 um 10:07 schrieb Pekka Paalanen: > >> > >>> On W

Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

On Tue, 29 Jun 2021 08:12:54 + Simon Ser wrote: > On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen > wrote: > > > yes, I think this makes sense, even if it is a property that one can't > > tell for sure what it does before hand. > > > > Using

Re: New uAPI for color management proposal and feedback request

On Wed, 12 May 2021 16:04:16 +0300 Ville Syrjälä wrote: > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: > > Hello, > > > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm > > properties I propose 4 new properties: > > "preferred pixel encoding",

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On Mon, 26 Apr 2021 13:38:49 -0400 Harry Wentland wrote: > ## Introduction > > We are looking to enable HDR support for a couple of single-plane and > multi-plane scenarios. To do this effectively we recommend new > interfaces to drm_plane. Below I'll give a bit of background on HDR > and why

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On Wed, 28 Apr 2021 13:24:27 +0530 Shashank Sharma wrote: > Assuming these details, A compositor will look for DRM color properties like > these: > > 1. Degamma plane property : To make buffers linear for Gamut mapping > > 2. Gamut mapping plane property:  To gamut map SRGB buffer to BT2020

Re: [RFC PATCH 1/3] drm/color: Add RGB Color encodings

On Mon, 26 Apr 2021 22:08:55 +0300 Ville Syrjälä wrote: > On Mon, Apr 26, 2021 at 02:56:26PM -0400, Harry Wentland wrote: > > On 2021-04-26 2:07 p.m., Ville Syrjälä wrote: > > > On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote: > > >> From: Bhawanpreet Lakha > > >> > > >> Add

Re: Color mode exposed to user space?

On Thu, 25 Mar 2021 12:12:09 -0400 Alex Deucher wrote: > + dri-devel > > I don't think it's currently exposed anywhere. > > Alex > > On Wed, Mar 24, 2021 at 5:11 AM Werner Sembach > wrote: > > > > Hello, > > > > is the information which color mode is currently in used for a display > >

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On Mon, 16 Aug 2021 15:37:23 +0200 sebast...@sebastianwick.net wrote: > On 2021-08-16 14:40, Harry Wentland wrote: > > On 2021-08-16 7:10 a.m., Brian Starkey wrote: > >> On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote: > >>> Hello Brian, > >>> (+Uma in cc) > >>> > >>> Thanks

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On Fri, 30 Jul 2021 16:41:29 -0400 Harry Wentland wrote: > Use the new DRM RFC doc section to capture the RFC previously only > described in the cover letter at > https://patchwork.freedesktop.org/series/89506/ > > v3: > * Add sections on single-plane and multi-plane HDR > * Describe approach

Re: New uAPI for color management proposal and feedback request v2

On Tue, 3 Aug 2021 11:38:19 +0200 Werner Sembach wrote: > Greetings, > > Original proposal: > https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg62387.html > > Abstract: Add "preferred color format", "active color format", "active bpc", > and "active Broadcast RGB" drm properties,

Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

On Wed, 14 Jul 2021 20:18:57 +0200 Werner Sembach wrote: > Am 01.07.21 um 13:30 schrieb Werner Sembach: > > Am 01.07.21 um 09:42 schrieb Pekka Paalanen: > >> On Wed, 30 Jun 2021 11:42:10 +0200 > >> Werner Sembach wrote: > >> > >>> Am 30.06.21

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On Wed, 22 Sep 2021 11:28:37 -0400 Harry Wentland wrote: > On 2021-09-22 04:31, Pekka Paalanen wrote: > > On Tue, 21 Sep 2021 14:05:05 -0400 > > Harry Wentland wrote: > > > >> On 2021-09-21 09:31, Pekka Paalanen wrote: > >>> On Mon, 20 Sep 2021

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On Wed, 22 Sep 2021 11:06:53 -0400 Harry Wentland wrote: > On 2021-09-20 20:14, Harry Wentland wrote: > > On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 > > -0400 > >> Harry Wentland wrote: > >> > > > > >>

Repository for additional color and HDR related documentation (Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC)

On Thu, 23 Sep 2021 10:43:54 +0300 Pekka Paalanen wrote: > On Wed, 22 Sep 2021 11:28:37 -0400 > Harry Wentland wrote: > > > On 2021-09-22 04:31, Pekka Paalanen wrote: > > > On Tue, 21 Sep 2021 14:05:05 -0400 > > > Harry Wentland wrote: > > >

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On Tue, 21 Sep 2021 14:05:05 -0400 Harry Wentland wrote: > On 2021-09-21 09:31, Pekka Paalanen wrote: > > On Mon, 20 Sep 2021 20:14:50 -0400 > > Harry Wentland wrote: > > > >> On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 > &g

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On Mon, 20 Sep 2021 20:14:50 -0400 Harry Wentland wrote: > On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 -0400 > > Harry Wentland wrote: > > > >> Use the new DRM RFC doc section to capture the RFC previously only > >> describ

Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

On Mon, 22 Nov 2021 15:42:38 -0700 jim.cro...@gmail.com wrote: > On Mon, Nov 22, 2021 at 2:02 AM Pekka Paalanen wrote: > > > > On Fri, 19 Nov 2021 11:21:36 -0500 > > Jason Baron wrote: > > > > > On 11/18/21 10:24 AM, Pekka Paalanen wrote: > &

Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

On Fri, 12 Nov 2021 10:08:41 -0500 Jason Baron wrote: > On 11/12/21 6:49 AM, Vincent Whitchurch wrote: > > On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote: > >> Sean Paul proposed, in: > >>

Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

On Fri, 19 Nov 2021 11:21:36 -0500 Jason Baron wrote: > On 11/18/21 10:24 AM, Pekka Paalanen wrote: > > On Thu, 18 Nov 2021 09:29:27 -0500 > > Jason Baron wrote: > > > >> On 11/16/21 3:46 AM, Pekka Paalanen wrote: > >>> On Fri, 12 Nov 20

Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

On Thu, 18 Nov 2021 09:29:27 -0500 Jason Baron wrote: > On 11/16/21 3:46 AM, Pekka Paalanen wrote: > > On Fri, 12 Nov 2021 10:08:41 -0500 > > Jason Baron wrote: > > > >> On 11/12/21 6:49 AM, Vincent Whitchurch wrote: > >>> On Thu, Nov 11,

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

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

  1   2   3   >