On Mon, 16 Jun 2025 11:30:23 +
"Borah, Chaitanya Kumar" wrote:
> > -Original Message-
> > From: Alex Hung
> > Sent: Wednesday, April 30, 2025 6:41 AM
> > To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > Cc: wayland-de...@lists.freedesktop.org; harry.wentl...@amd
On Wed, 4 Jun 2025 18:59:22 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Harry Wentland
> > Sent: Wednesday, June 4, 2025 1:57 AM
> > To: Pekka Paalanen ; Shankar, Uma
> >
> > Cc: Simon Ser ; Alex Hu
On Tue, 3 Jun 2025 08:30:23 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Pekka Paalanen
> > Sent: Friday, May 30, 2025 7:28 PM
> > To: Shankar, Uma
> > Cc: Simon Ser ; Harry Wentland
> > ; Alex Hung ; dri-
> > de...@
On Thu, 22 May 2025 11:33:00 +
"Shankar, Uma" wrote:
> One request though: Can we enhance the lut samples from existing 16bits to
> 32bits as lut precision is
> going to be more than 16 in certain hardware. While adding the new UAPI, lets
> extend this to 32 to make it future proof.
> Refer
On Thu, 22 May 2025 09:54:50 -0400
Harry Wentland wrote:
> On 2025-05-22 09:49, Simon Ser wrote:
> > On Thursday, May 22nd, 2025 at 15:28, Harry Wentland
> > wrote:
> >
> What we should
> do is reject YCbCr-type buffers with the color pipeline until we
> implement support for
On Wed, 21 May 2025 15:48:00 -0400
Harry Wentland wrote:
> On 2025-05-17 07:51, Xaver Hugl wrote:
> > Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro
> > :
> >>
> >>
> >>
> >> On 5/15/25 15:39, Daniel Stone wrote:
> >>> Hi,
> >>>
> >>> On Thu, 15 May 2025 at 19:02, Harry Wentland
On Tue, 13 May 2025 16:39:51 -0400
Harry Wentland wrote:
> On 2025-05-13 11:36, Melissa Wen wrote:
> > On 05/13, Pekka Paalanen wrote:
> >> On Mon, 12 May 2025 15:50:17 -0300
> >> Melissa Wen wrote:
> >>
> >>> On 04/29, Alex Hung wrote:
>
On Mon, 12 May 2025 15:50:17 -0300
Melissa Wen wrote:
> On 04/29, Alex Hung wrote:
> > Expose one 1D curve colorop with support for
> > DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
> > the sRGB transform when the colorop is not in bypass.
> >
> > With this change the following IGT te
CbCr formats in the
> display
> + * pipeline, with the Cb and Cr implicitly neutral (0.0 in nominal values).
> This
> + * also means that COLOR_RANGE property applies to the Y-only formats.
> + *
> + */
> +
> +#define DRM_FORMAT_Y8fourcc_code('G', 'R', 'E', 'Y') /*
> 8-bit Y-only */
>
> /*
> * Format Modifiers:
>
Reviewed-by: Pekka Paalanen
Thanks,
pq
pgpM3J0l19Xhb.pgp
Description: OpenPGP digital signature
On Fri, 25 Apr 2025 11:38:28 +0300
Tomi Valkeinen wrote:
> Hi Pekka,
>
> On 17/04/2025 11:13, Pekka Paalanen wrote:
> >> My understanding is that the Y-only pixel formats behave in a well
> >> defined way (or, as well defined as the YUV formats), and there's
&
On Thu, 17 Apr 2025 15:19:45 +
Simon Ser wrote:
> On Monday, April 14th, 2025 at 13:06, Pekka Paalanen
> wrote:
>
> > Looking good, but given the new wording is 100% mine, not sure I can
> > give reviewed-by?
> >
> > Co-authored-by maybe?
>
> Sin
On Tue, 22 Apr 2025 12:12:21 +0200
Geert Uytterhoeven wrote:
> Hi Pekka,
>
> On Tue, 22 Apr 2025 at 12:01, Pekka Paalanen wrote:
> > On Tue, 22 Apr 2025 11:41:29 +0200
> > Geert Uytterhoeven wrote:
> > > On Tue, 22 Apr 2025 at 11:11, Pekka Paalanen
> >
On Tue, 22 Apr 2025 11:41:29 +0200
Geert Uytterhoeven wrote:
> Hi Pekka,
>
> On Tue, 22 Apr 2025 at 11:11, Pekka Paalanen
> wrote:
> > On Mon, 21 Apr 2025 17:50:39 +0300
> > Laurent Pinchart wrote:
> > > On Thu, Apr 17, 2025 at 11:13:15AM +0300, Pekka Paa
On Mon, 21 Apr 2025 17:50:39 +0300
Laurent Pinchart wrote:
> Hi Pekka,
>
> On Thu, Apr 17, 2025 at 11:13:15AM +0300, Pekka Paalanen wrote:
> > On Wed, 16 Apr 2025 11:59:43 +0300 Tomi Valkeinen wrote:
> > > On 01/04/2025 16:27, Pekka Paalanen wrote:
> > > >
ine-dependent,
> + * you can't cast it directly to AR48 or xR48.
> + */
> struct pixel_argb_u16 {
> u16 a, r, g, b;
> };
>
Reviewed-by: Pekka Paalanen
(re-sent through a different address due issues on my side)
Thanks,
pq
pgpKpA9CkeWCj.pgp
Description: OpenPGP digital signature
On Wed, 16 Apr 2025 11:59:43 +0300
Tomi Valkeinen wrote:
> Hi,
>
> On 01/04/2025 16:27, Pekka Paalanen wrote:
> > On Mon, 31 Mar 2025 13:53:37 +0300
> > Pekka Paalanen wrote:
> >
> >> On Mon, 31 Mar 2025 11:21:35 +0300
> >> Laurent Pinchart wrot
ine-dependent,
> + * you can't cast it directly to AR48 or xR48.
> + */
> struct pixel_argb_u16 {
> u16 a, r, g, b;
> };
>
Reviewed-by: Pekka Paalanen
Thanks,
pq
pgpGrbvawhpjk.pgp
Description: OpenPGP digital signature
On Tue, 15 Apr 2025 11:29:10 -0400
Harry Wentland wrote:
> On 2025-04-10 03:53, Pekka Paalanen wrote:
> > On Tue, 8 Apr 2025 13:30:46 -0400
> > Harry Wentland wrote:
> >
> >> On 2025-04-08 12:40, Daniel Stone wrote:
> >>> Hi there,
> >>&g
On Thu, 17 Apr 2025 06:31:21 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Intel-xe On Behalf Of Murthy,
> > Arun R
> > Sent: Friday, March 28, 2025 10:36 AM
> > To: Pekka Paalanen
> > Cc: intel...@lists.freedesktop.org
On Mon, 14 Apr 2025 08:56:56 +
Simon Ser wrote:
> Explain how to perform front-buffer rendering.
>
> v2: apply Pekka's rewrite
>
> Signed-off-by: Simon Ser
> Cc: Pekka Paalanen
> Cc: Simona Vetter
> ---
> drivers/gpu/drm/drm_blend.c | 6 ++
On Tue, 8 Apr 2025 13:30:46 -0400
Harry Wentland wrote:
> On 2025-04-08 12:40, Daniel Stone wrote:
> > Hi there,
> >
> > On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
> >> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone
> >> wrote:
...
> >>> 1. Is it guaranteed that, if any plane on
On Mon, 31 Mar 2025 17:54:56 +0300
Laurent Pinchart wrote:
> On Mon, Mar 31, 2025 at 01:53:37PM +0300, Pekka Paalanen wrote:
> > On Mon, 31 Mar 2025 11:21:35 +0300 Laurent Pinchart wrote:
> > > On Mon, Mar 31, 2025 at 10:54:46AM +0300, Pekka Paalanen wrote:
> > >
On Mon, 31 Mar 2025 13:53:37 +0300
Pekka Paalanen wrote:
> On Mon, 31 Mar 2025 11:21:35 +0300
> Laurent Pinchart wrote:
>
> > On Mon, Mar 31, 2025 at 10:54:46AM +0300, Pekka Paalanen wrote:
> > > On Thu, 27 Mar 2025 17:35:39 +0100
> > > Geert Uytterhoeven w
On Mon, 31 Mar 2025 11:21:35 +0300
Laurent Pinchart wrote:
> On Mon, Mar 31, 2025 at 10:54:46AM +0300, Pekka Paalanen wrote:
> > On Thu, 27 Mar 2025 17:35:39 +0100
> > Geert Uytterhoeven wrote:
> >
> > > Hi Pekka,
> > >
> > > On Thu, 2
On Thu, 27 Mar 2025 17:35:39 +0100
Geert Uytterhoeven wrote:
> Hi Pekka,
>
> On Thu, 27 Mar 2025 at 16:59, Pekka Paalanen
> wrote:
> > On Thu, 27 Mar 2025 16:21:16 +0200
> > Tomi Valkeinen wrote:
> > > On 27/03/2025 11:20, Pekka Paalanen wrote:
> >
On Thu, 27 Mar 2025 16:21:16 +0200
Tomi Valkeinen wrote:
> Hi,
>
> On 27/03/2025 11:20, Pekka Paalanen wrote:
> > On Wed, 26 Mar 2025 15:55:18 +0200
> > Tomi Valkeinen wrote:
> >
> >> Hi,
> >>
> >> On 26/03/2025 15:52, Geert Uytterhoe
On Wed, 26 Mar 2025 15:55:18 +0200
Tomi Valkeinen wrote:
> Hi,
>
> On 26/03/2025 15:52, Geert Uytterhoeven wrote:
> > Hi Tomi,
> >
> > On Wed, 26 Mar 2025 at 14:23, Tomi Valkeinen
> > wrote:
> >> Add greyscale Y8 format.
> >>
> >> Acked-by: Dmitry Baryshkov
> >> Signed-off-by: Tomi Valkeine
On Wed, 26 Mar 2025 06:03:27 +
"Murthy, Arun R" wrote:
> > On Wed, 19 Mar 2025 12:08:15 +
> > "Murthy, Arun R" wrote:
> >
> > > > On Mon, 3 Mar 2025 13:23:42 +0530
> > > > "Murthy, Arun R" wrote:
> > >
On Wed, 19 Mar 2025 12:08:15 +
"Murthy, Arun R" wrote:
> > On Mon, 3 Mar 2025 13:23:42 +0530
> > "Murthy, Arun R" wrote:
> >
> > > On 20-02-2025 21:20, Pekka Paalanen wrote:
> > > > On Wed, 19 Feb 2025 09:28:51 +0530
> &g
On Fri, 7 Mar 2025 15:50:41 +0100
Louis Chauvet wrote:
> Le 07/03/2025 à 11:20, Maxime Ripard a écrit :
> > On Wed, Feb 19, 2025 at 02:35:14PM +0100, Louis Chauvet wrote:
> >>
> >>
> >> Le 19/02/2025 à 11:15, Maxime Ripard a écrit :
> >>> On Wed, Feb 05, 2025 at 04:32:07PM +0100, Louis Chauve
On Mon, 3 Mar 2025 13:22:29 +0530
"Murthy, Arun R" wrote:
> On 17-02-2025 17:57, Pekka Paalanen wrote:
> > On Mon, 17 Feb 2025 12:08:08 +0200
> > Pekka Paalanen wrote:
> >
> >> Hi Arun,
> >>
> >> this whole series seems to be missi
On Mon, 3 Mar 2025 13:23:42 +0530
"Murthy, Arun R" wrote:
> On 20-02-2025 21:20, Pekka Paalanen wrote:
> > On Wed, 19 Feb 2025 09:28:51 +0530
> > "Murthy, Arun R" wrote:
> >
> >> On 18-02-2025 21:48, Pekka Paalanen wrote:
> >>> O
On Wed, 19 Feb 2025 09:28:51 +0530
"Murthy, Arun R" wrote:
> On 18-02-2025 21:48, Pekka Paalanen wrote:
> > On Tue, 18 Feb 2025 11:13:39 +0530
> > "Murthy, Arun R" wrote:
> >
> >> On 17-02-2025 15:38, Pekka Paalanen wrote:
> >>>
On Tue, 18 Feb 2025 11:13:39 +0530
"Murthy, Arun R" wrote:
> On 17-02-2025 15:38, Pekka Paalanen wrote:
> > Hi Arun,
> >
> > this whole series seems to be missing all the UAPI docs for the DRM
> > ReST files, e.g. drm-kms.rst. The UAPI header doc comments
On Mon, 17 Feb 2025 12:08:08 +0200
Pekka Paalanen wrote:
> Hi Arun,
>
> this whole series seems to be missing all the UAPI docs for the DRM
> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> replacement for them, I would assume both are a requirement.
>
Hi Arun,
this whole series seems to be missing all the UAPI docs for the DRM
ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
replacement for them, I would assume both are a requirement.
Without the ReST docs it is really difficult to see how this new UAPI
should be used.
On
On Tue, 28 Jan 2025 11:37:53 +0200
Raag Jadav wrote:
> On Mon, Jan 27, 2025 at 12:23:28PM +0200, Pekka Paalanen wrote:
> > On Wed, 22 Jan 2025 07:22:25 +0200
> > Raag Jadav wrote:
> >
> > > On Tue, Jan 21, 2025 at 02:14:56AM +0100, Xaver Hugl wrote:
> >
On Thu, 23 Jan 2025 15:16:29 -0500
Harry Wentland wrote:
> On 2025-01-17 04:06, Pekka Paalanen wrote:
> > On Thu, 16 Jan 2025 10:56:22 +0200
> > Pekka Paalanen wrote:
> >
> >> On Thu, 19 Dec 2024 21:33:37 -0700
> >> Alex Hung wrote:
> >>
&g
On Wed, 22 Jan 2025 07:22:25 +0200
Raag Jadav wrote:
> On Tue, Jan 21, 2025 at 02:14:56AM +0100, Xaver Hugl wrote:
> > > +It is the responsibility of the consumer to make sure that the device or
> > > +its resources are not in use by any process before attempting recovery.
> > I'm not convinced
er CRTCs
> sharing a DP-MST connector).
>
> Signed-off-by: Simon Ser
> Cc: Simona Vetter
> Cc: Ville Syrjälä
> Cc: Pekka Paalanen
> Cc: David Turner
> ---
> include/uapi/drm/drm_mode.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/uapi/drm/dr
On Thu, 19 Dec 2024 21:33:49 -0700
Alex Hung wrote:
> From: Harry Wentland
>
> Add kernel doc for AMD color pipeline.
>
> Signed-off-by: Alex Hung
> Signed-off-by: Harry Wentland
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 122 +++---
> 1 file changed, 102 insertions
On Thu, 16 Jan 2025 10:56:22 +0200
Pekka Paalanen wrote:
> On Thu, 19 Dec 2024 21:33:37 -0700
> Alex Hung wrote:
>
> > From: Harry Wentland
> >
> > The BT.709 and BT.2020 OETFs are the same, the only difference
> > being that the BT.2020 variant is defined w
On Thu, 19 Dec 2024 21:33:35 -0700
Alex Hung wrote:
> From: Harry Wentland
>
> The PQ function defines a mapping of code values to nits (cd/m^2).
> The max code value maps to 10,000 nits.
>
> Windows DWM's canonical composition color space (CCCS) defaults
> to composing SDR contents to 80 nit
On Thu, 19 Dec 2024 21:33:37 -0700
Alex Hung wrote:
> From: Harry Wentland
>
> The BT.709 and BT.2020 OETFs are the same, the only difference
> being that the BT.2020 variant is defined with more precision
> for 10 and 12-bit per color encodings.
>
> Both are used as encoding functions for vid
On Mon, 13 May 2024 09:15:13 +0200
Louis Chauvet wrote:
> Le 22/04/24 - 14:07, Pekka Paalanen a écrit :
> > On Tue, 09 Apr 2024 15:25:25 +0200
> > Louis Chauvet wrote:
> >
> > > Introduce the usage of block_h/block_w to compute the offset and the
> >
On Thu, 09 May 2024 09:06:29 -0400
nerdopolis wrote:
> Hi
>
> So I have been made aware of an apparent race condition of some
> drivers taking a bit longer to load, which could lead to a possible
> race condition of display servers/greeters using the simpledrm
> device, and then experiencing pro
orted
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 8f764a108b00..67f891e7ac58 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -30,6 +30,10 @@ static const u32 vkms_formats[] = {
> DRM_FORMAT_YVU420,
> DRM_FORMAT_YVU422,
> DRM_FORMAT_YVU444,
> + DRM_FORMAT_R1,
> + DRM_FORMAT_R2,
> + DRM_FORMAT_R4,
> + DRM_FORMAT_R8,
> };
>
> static struct drm_plane_state *
>
This patch looks good to me, and the R8_read_line() is ok to have
separately, I guess for performance reasons.
I suggested a way to reduce the repetition between R1, R2, R4 a little
bit. With or without that:
Reviewed-by: Pekka Paalanen
Thanks,
pq
pgp4F6tyhPV45.pgp
Description: OpenPGP digital signature
est.c
> b/drivers/gpu/drm/vkms/tests/vkms_format_test.c
> new file mode 100644
> index ..c7c556b4fd98
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/tests/vkms_format_test.c
> @@ -0,0 +1,230 @@
> +// SPDX-License-Identifier: GPL-2.0+
Hi,
what's the ke
s64 fp_r, fp_g, fp_b;
This part belongs in the previous patch.
Otherwise,
Acked-by: Pekka Paalanen
Thanks,
pq
>
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index d4e375913122..8f764a108b00 100644
> --- a/drivers/gpu/dr
On Tue, 09 Apr 2024 15:25:30 +0200
Louis Chauvet wrote:
> From: Arthur Grillo
>
> Add support to the YUV formats bellow:
>
> - NV12/NV16/NV24
> - NV21/NV61/NV42
> - YUV420/YUV422/YUV444
> - YVU420/YVU422/YVU444
>
> The conversion from yuv to rgb is done with fixed-point arithmetic, using
> 32
On Tue, 09 Apr 2024 15:25:28 +0200
Louis Chauvet wrote:
> Re-introduce a line-by-line composition algorithm for each pixel format.
> This allows more performance by not requiring an indirection per pixel
> read. This patch is focused on readability of the code.
>
> Line-by-line composition was i
On Tue, 09 Apr 2024 15:25:27 +0200
Louis Chauvet wrote:
> The pixel_read_direction enum is useful to describe the reading direction
> in a plane. It avoids using the rotation property of DRM, which not
> practical to know the direction of reading.
> This patch also introduce two helpers, one to c
>
> if (!check_limit(plane[i]->frame_info, y_pos))
> continue;
>
> vkms_compose_row(stage_buffer, plane[i], y_pos);
> - pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer,
> - output_buffer);
> + pre_mul_alpha_blend(stage_buffer, output_buffer, x_dst,
> pixel_count);
> }
>
> apply_lut(crtc_state, output_buffer);
>
Reviewed-by: Pekka Paalanen
Thanks,
pq
pgpw9dqlXwnZA.pgp
Description: OpenPGP digital signature
On Tue, 09 Apr 2024 15:25:25 +0200
Louis Chauvet wrote:
> Introduce the usage of block_h/block_w to compute the offset and the
> pointer of a pixel. The previous implementation was specialized for
> planes with block_h == block_w == 1. To avoid confusion and allow easier
> implementation of tiled
+ * @src: source rectangle of this frame in the source framebuffer
> + * @dst: destination rectangle in the crtc buffer
Are both src and dst using whole pixel units, or is src using 1/65536th
pixel units?
Asking because UAPI has src rect in 16.16 fixed-point, IIRC.
With that clarified:
Acked-b
On Wed, 17 Apr 2024 00:30:58 +0200
Louis Chauvet wrote:
> Le 15/04/24 - 15:00, Pekka Paalanen a écrit :
> > On Tue, 09 Apr 2024 12:04:07 +0200
> > Louis Chauvet wrote:
> >
> > > Let's provide more details about the drm_format_info structure b
On Wed, 17 Apr 2024 00:30:58 +0200
Louis Chauvet wrote:
> Le 15/04/24 - 14:36, Pekka Paalanen a écrit :
> > On Tue, 09 Apr 2024 12:04:06 +0200
> > Louis Chauvet wrote:
> >
> > > The expected behavior of the rotation property was not very clear. Add
> > &g
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 Tue, 09 Apr 2024 12:04:07 +0200
Louis Chauvet wrote:
> Let's provide more details about the drm_format_info structure because
> its content may not be straightforward for someone not used to video
> formats and drm internals.
>
> Signed-off-by: Louis Chauvet
> ---
> include/drm/drm_fourcc.h
On Tue, 09 Apr 2024 12:04:06 +0200
Louis Chauvet wrote:
> The expected behavior of the rotation property was not very clear. Add
> more examples to explain what is the expected result.
>
> Signed-off-by: Louis Chauvet
> ---
> drivers/gpu/drm/drm_blend.c | 52
>
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 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 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 Mon, 8 Apr 2024 09:50:19 +0200
Louis Chauvet wrote:
> Le 27/03/24 - 16:23, Pekka Paalanen a écrit :
> > On Wed, 13 Mar 2024 18:45:05 +0100
> > Louis Chauvet wrote:
> >
> > > From: Arthur Grillo
> > >
> > > Add support to the YUV formats be
On Mon, 8 Apr 2024 09:50:18 +0200
Louis Chauvet wrote:
> Le 27/03/24 - 14:16, Pekka Paalanen a écrit :
> > On Tue, 26 Mar 2024 16:57:00 +0100
> > Louis Chauvet wrote:
> >
> > > Le 25/03/24 - 15:11, Pekka Paalanen a écrit :
> > > > On Wed, 13 Mar
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 Wed, 3 Apr 2024 07:44:54 -0400
Zack Rusin wrote:
> On Wed, Apr 3, 2024 at 3:43 AM Pekka Paalanen
> wrote:
> >
> > On Tue, 2 Apr 2024 19:28:13 -0400
> > Zack Rusin wrote:
> >
> > > The table of primary plane formats wasn't sorted at all, lea
On Tue, 2 Apr 2024 19:28:13 -0400
Zack Rusin wrote:
> The table of primary plane formats wasn't sorted at all, leading to
> applications picking our least desirable formats by defaults.
>
> Sort the primary plane formats according to our order of preference.
This is good.
> Fixes IGT's kms_at
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
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 Wed, 13 Mar 2024 18:45:10 +0100
Louis Chauvet wrote:
> This add the support for:
> - R1/R2/R4/R8
>
> R1 format was tested with [1] and [2].
>
> [1]:
> https://lore.kernel.org/r/20240313-new_rotation-v2-0-6230fd5ca...@bootlin.com
> [2]:
> https://lore.kernel.org/igt-dev/20240306-b4-kms_test
in_legal = False,
> > +* in_int = True,
> > +* out_bits = 8,
> > +* out_legal = False,
> > +* out_int = True)
> > +*/
>
> I feel that this Pyth
On Wed, 27 Mar 2024 13:29:16 +0200
Pekka Paalanen wrote:
> On Wed, 27 Mar 2024 07:11:48 +
> "Garg, Nemesa" wrote:
>
> > > -Original Message-
> > > From: Pekka Paalanen
> > > Sent: Wednesday, March 13, 2024 3:07 PM
>
On Wed, 13 Mar 2024 18:45:05 +0100
Louis Chauvet wrote:
> From: Arthur Grillo
>
> Add support to the YUV formats bellow:
>
> - NV12/NV16/NV24
> - NV21/NV61/NV42
> - YUV420/YUV422/YUV444
> - YVU420/YVU422/YVU444
>
> The conversion from yuv to rgb is done with fixed-point arithmetic, using
> 32
On Tue, 26 Mar 2024 16:57:03 +0100
Louis Chauvet wrote:
> Le 25/03/24 - 11:26, Maíra Canal a écrit :
> > On 3/13/24 14:45, Louis Chauvet wrote:
> > > From: Arthur Grillo
> > >
> > > Add support to the YUV formats bellow:
> > >
> > > - NV12/NV16/NV24
> > > - NV21/NV61/NV42
> > > - YUV420/YUV4
On Tue, 26 Mar 2024 16:57:02 +0100
Louis Chauvet wrote:
> [...]
>
> > > @@ -215,34 +188,146 @@ static void blend(struct vkms_writeback_job *wb,
> > > {
> > > struct vkms_plane_state **plane = crtc_state->active_planes;
> > > u32 n_active_planes = crtc_state->num_active_planes;
> > > - int y
On Tue, 26 Mar 2024 16:57:00 +0100
Louis Chauvet wrote:
> Le 25/03/24 - 15:11, Pekka Paalanen a écrit :
> > On Wed, 13 Mar 2024 18:45:03 +0100
> > Louis Chauvet wrote:
> >
> > > The pixel_read_direction enum is useful to describe the reading direction
> &g
On Tue, 26 Mar 2024 16:57:00 +0100
Louis Chauvet wrote:
> Le 25/03/24 - 14:41, Pekka Paalanen a écrit :
> > On Wed, 13 Mar 2024 18:45:02 +0100
> > Louis Chauvet wrote:
> >
> > > The pre_mul_alpha_blend is dedicated to blending, so to avoid mixing
> &
On Wed, 27 Mar 2024 07:11:48 +
"Garg, Nemesa" wrote:
> > -Original Message-
> > From: Pekka Paalanen
> > Sent: Wednesday, March 13, 2024 3:07 PM
> > To: Garg, Nemesa
> > Cc: Simon Ser ; intel-...@lists.freedesktop.org; dri-
> > de...@l
* @format: DRM_FORMAT_* value for which to obtain a conversion function
> (see [drm_fourcc.h])
> */
> -pixel_read_t get_pixel_read_function(u32 format)
> +pixel_read_line_t get_pixel_read_line_function(u32 format)
> {
> switch (format) {
> case DRM_FORMAT_ARGB:
> - return &ARGB_to_argb_u16;
> + return &ARGB_read_line;
> case DRM_FORMAT_XRGB:
> - return &XRGB_to_argb_u16;
> + return &XRGB_read_line;
> case DRM_FORMAT_ARGB16161616:
> - return &ARGB16161616_to_argb_u16;
> + return &ARGB16161616_read_line;
> case DRM_FORMAT_XRGB16161616:
> - return &XRGB16161616_to_argb_u16;
> + return &XRGB16161616_read_line;
> case DRM_FORMAT_RGB565:
> - return &RGB565_to_argb_u16;
> + return &RGB565_read_line;
> default:
> /*
>* This is a bug in vkms_plane_atomic_check. All the supported
> diff --git a/drivers/gpu/drm/vkms/vkms_formats.h
> b/drivers/gpu/drm/vkms/vkms_formats.h
> index 3ecea4563254..8d2bef95ff79 100644
> --- a/drivers/gpu/drm/vkms/vkms_formats.h
> +++ b/drivers/gpu/drm/vkms/vkms_formats.h
> @@ -5,7 +5,7 @@
>
> #include "vkms_drv.h"
>
> -pixel_read_t get_pixel_read_function(u32 format);
> +pixel_read_line_t get_pixel_read_line_function(u32 format);
>
> pixel_write_t get_pixel_write_function(u32 format);
>
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 10e9b23dab28..8875bed76410 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -112,7 +112,6 @@ static void vkms_plane_atomic_update(struct drm_plane
> *plane,
> frame_info = vkms_plane_state->frame_info;
> memcpy(&frame_info->src, &new_state->src, sizeof(struct drm_rect));
> memcpy(&frame_info->dst, &new_state->dst, sizeof(struct drm_rect));
> - memcpy(&frame_info->rotated, &new_state->dst, sizeof(struct drm_rect));
> frame_info->fb = fb;
> memcpy(&frame_info->map, &shadow_plane_state->data,
> sizeof(frame_info->map));
> drm_framebuffer_get(frame_info->fb);
> @@ -122,10 +121,8 @@ static void vkms_plane_atomic_update(struct drm_plane
> *plane,
>
> DRM_MODE_REFLECT_X |
>
> DRM_MODE_REFLECT_Y);
>
> - drm_rect_rotate(&frame_info->rotated,
> drm_rect_width(&frame_info->rotated),
> - drm_rect_height(&frame_info->rotated),
> frame_info->rotation);
>
> - vkms_plane_state->pixel_read = get_pixel_read_function(fmt);
> + vkms_plane_state->pixel_read_line = get_pixel_read_line_function(fmt);
> }
>
> static int vkms_plane_atomic_check(struct drm_plane *plane,
>
This is looking good enough that I can give an
Acked-by: Pekka Paalanen
Thanks,
pq
pgprCr6kRnsWN.pgp
Description: OpenPGP digital signature
On Mon, 25 Mar 2024 11:15:13 -0300
Maíra Canal wrote:
> On 3/13/24 14:45, Louis Chauvet wrote:
> > Re-introduce a line-by-line composition algorithm for each pixel format.
> > This allows more performance by not requiring an indirection per pixel
> > read. This patch is focused on readability of
On Wed, 13 Mar 2024 18:45:03 +0100
Louis Chauvet wrote:
> The pixel_read_direction enum is useful to describe the reading direction
> in a plane. It avoids using the rotation property of DRM, which not
> practical to know the direction of reading.
> This patch also introduce two helpers, one to c
On Wed, 13 Mar 2024 18:45:02 +0100
Louis Chauvet wrote:
> The pre_mul_alpha_blend is dedicated to blending, so to avoid mixing
> different concepts (coordinate calculation and color management), extract
> the x_limit and x_dst computation outside of this helper.
> It also increases the maintainab
On Wed, 13 Mar 2024 18:45:01 +0100
Louis Chauvet wrote:
> Introduce the usage of block_h/block_w to compute the offset and the
> pointer of a pixel. The previous implementation was specialized for
> planes with block_h == block_w == 1. To avoid confusion and allow easier
> implementation of tiled
On Wed, 13 Mar 2024 18:45:00 +0100
Louis Chauvet wrote:
> As the pixel_read and pixel_write function should never modify the input
> buffer, mark those pointers const.
>
> Signed-off-by: Louis Chauvet
Reviewed-by: Pekka Paalanen
Thanks,
pq
> ---
> drivers/gpu/d
&format);
> - return (pixel_read_t)NULL;
> + return &black_to_argb_u16;
Hi Louis,
I'm perhaps a bit paranoid in these things, but I'd make this not
black. Maybe something more "screaming" like magenta. There is a slight
chance that
callbacks, it should never append.
s/append/happen/
Reviewed-by: Pekka Paalanen
Thanks,
pq
>
> Document for those typedefs.
>
> Signed-off-by: Louis Chauvet
> ---
> drivers/gpu/drm/vkms/vkms_drv.h | 23 ++-
> drivers/gpu/drm/vkms/vkms_formats.c | 124
> +++
On Wed, 13 Mar 2024 18:44:56 +0100
Louis Chauvet wrote:
> From: Arthur Grillo
>
> Remove intermidiary variables and access the variables directly from
> drm_frame. These changes should be noop.
>
> Signed-off-by: Arthur Grillo
> Signed-off-by: Louis Chauvet
> ---
On Wed, 13 Mar 2024 18:44:55 +0100
Louis Chauvet wrote:
> Few no-op changes to remove double spaces and fix wrong alignments.
>
> Signed-off-by: Louis Chauvet
Reviewed-by: Pekka Paalanen
Thanks,
pq
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 10 +-
> dr
On Wed, 13 Mar 2024 15:45:47 +0100
Xaver Hugl wrote:
> Hi all,
>
> This was already discussed on IRC, but I think this should be on the
> mailing list as well and get some more official conclusion that's
> written down somewhere.
>
> Recently I've experienced a GPU reset, which the system succe
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: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
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
.pekka.paala...@collabora.com/
> > >>
> > > Hi Arthur,
> > >
> > > thanks for addressing this issue.
> > >
> > > Please, add a fix tag to the commit that you are fixing, so we can
> > > easily backport. Might be this commit:
> > > htt
On Mon, 11 Mar 2024 17:06:34 +0100
Sebastian Wick wrote:
> On Thu, Mar 07, 2024 at 10:29:22AM +0200, Pekka Paalanen wrote:
> > On Wed, 6 Mar 2024 17:42:09 +0100
> > Sebastian Wick wrote:
> >
> > > On Wed, Mar 06, 2024 at 10:27:21AM +0200, Pekka Paalanen wrote:
On Tue, 12 Mar 2024 16:26:00 +0200
Pekka Paalanen wrote:
> On Tue, 12 Mar 2024 08:30:34 +
> "Garg, Nemesa" wrote:
>
> > This KMS property is not implementing any formula
>
> Sure it is. Maybe Intel just does not want to tell what the algorithm
&g
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: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
1 - 100 of 1059 matches
Mail list logo
