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
clien
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
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
type.
> + However, try to not define colorops for "use cases", especially 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
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 include
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, but
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 nev
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
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 don'
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
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:
> - Comm
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 th
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 t
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
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 e
lative ordering between the planes matters.
Thanks,
pq
> 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/wayl
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 electio
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
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:
> >>>
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
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:
> >>
> >>
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, 2024 at 11:08 AM Pekka
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
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
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 user
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
to finish quickly and then spam 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 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
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
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
>
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
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
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,
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
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
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
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:
> >>
>
>
>
> >>
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:
> > >
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:
> >> https://urldefense.com/v3/__https://patchwork.freedesktop.org/series/78133/__;!!GjvTz_vk!HcKnM
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,
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
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:
> &
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
> > (RGB
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 we
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 t
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
>
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
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:
> >>>
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 spa
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
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:
> >>
> >>>
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
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:
> >>>
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 susp
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", "acti
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
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
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
>
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 and
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
>
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 su
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(+)
>
>
struct drm_property *active_bpc_property;
> +
> #define 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);
>
t; drm_connector *connector,
> 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
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 surel
* property.
> + */
> + 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 worke
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
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 ++-
> .../display/amdgpu_dm/amdgpu_dm_mst_t
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:
> >>
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
> h
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 besid
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 AMD
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:
> >>
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
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.
> >
> > Usin
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 u
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:
> >>
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 11
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
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
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
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
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 include/drm/drm
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 drm_crtc_state::acti
On Mon, 4 Jan 2021 16:07:58 -0500
Aurabindo Pillai wrote:
> [Why&How]
> 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 para
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
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 D
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 | 8
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
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:
>
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
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
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
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 me
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
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
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 descrip
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
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
On Tue, 30 Aug 2022 11:08:22 +0300
Ville Syrjälä wrote:
> On Mon, Aug 29, 2022 at 04:01:44PM +, Simon Ser wrote:
> > On Friday, August 26th, 2022 at 10:19, Ville Syrjälä
> > wrote:
> >
> > > On Wed, Aug 24, 2022 at 03:08:55PM +, Simon Ser wrote:
> > > > This new kernel capability i
1 - 100 of 215 matches
Mail list logo
