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
; 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 kernel
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
>
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
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
t;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
e 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-by: Pekka Paalane
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
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
>
On Mon, 15 Apr 2024 18:33:39 -0400
Leo Li wrote:
> On 2024-04-15 04:19, Pekka Paalanen wrote:
> > On Fri, 12 Apr 2024 16:14:28 -0400
> > Leo Li wrote:
> >
> >> On 2024-04-12 11:31, Alex Deucher wrote:
> >>> On Fri, Apr 12, 20
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
> ---
>
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, leading
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
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
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
q
> Some links to provide context and details:
> * What is underlay?:
> https://gitlab.freedesktop.org/emersion/libliftoff/-/issues/76
> * Discussion on how to implement underlay on Weston:
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258#note_2325164
>
>
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]:
>
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
>
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
> > > -
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
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
>
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
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 _to_argb_u16;
> + return _read_line;
> case DRM_FORMAT_XRGB:
> - return _to_argb_u16;
> + return _read_line;
> case DRM_FORMAT_ARGB16161616:
> - return _to_argb_u16;
> + return _read_line;
> case DRM_FORMAT_XRGB16161616:
> - return _to_argb_u16;
> + return _read_line;
> case DRM_FORMAT_RGB565:
> - return _to_argb_u16;
> + return _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(_info->src, _state->src, sizeof(struct drm_rect));
> memcpy(_info->dst, _state->dst, sizeof(struct drm_rect));
> - memcpy(_info->rotated, _state->dst, sizeof(struct drm_rect));
> frame_info->fb = fb;
> memcpy(_info->map, _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(_info->rotated,
> drm_rect_width(_info->rotated),
> - drm_rect_height(_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
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
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
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
);
> - return (pixel_read_t)NULL;
> + return _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 black might sometimes be expected,
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
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:
> -
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
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
.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:
> > >
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 never
> &g
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: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
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
SDR vs. HDR imagery?
Thanks,
pq
> > -Original Message-
> > From: dri-devel On Behalf Of Simon
> > Ser
> > Sent: Monday, March 4, 2024 7:46 PM
> > To: Garg, Nemesa
> > Cc: Pekka Paalanen ; intel-
> > g...@lists.freedesktop.org; dri-devel@lists
pecially if
> + they require you to combine multiple hardware blocks.
> +
> +- Design new colorops as prescriptive, not descriptive; by the
> + mathematical formula, not by the assumed input and output.
> +
> +A defined colorop type must be deterministic. The exact behavior of the
> +colorop must be documented entirely, whether via a mathematical formula
> +or some other description. Its operation can depend only on its
> +properties and input and nothing else, allowed error tolerance
> +notwithstanding.
> +
> +
> +Driver Forward/Backward Compatibility
> +=
> +
> +As this is uAPI drivers can't regress color pipelines that have been
> +introduced for a given HW generation. New HW generations are free to
> +abandon color pipelines advertised for previous generations.
> +Nevertheless, it can be beneficial to carry support for existing color
> +pipelines forward as those will likely already have support in DRM
> +clients.
> +
> +Introducing new colorops to a pipeline is fine, as long as they can be
> +bypassed or are purely informational. DRM clients implementing support
> +for the pipeline can always skip unknown properties as long as they can
> +be confident that doing so will not cause unexpected results.
> +
> +If a new colorop doesn't fall into one of the above categories
> +(bypassable or informational) the modified pipeline would be unusable
> +for user space. In this case a new pipeline should be defined.
> +
> +
> +References
> +==
> +
> +1.
> https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1QWn488=@emersion.fr/
> \ No newline at end of file
All in all, I think this is good enough to have my
Acked-by: Pekka Paalanen
in spite of the comments I had. They are just fine tuning.
Thanks,
pq
pgpqA8Xx126xx.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
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,
y much a de-facto standard now and we can provide helpers for it.
> >
> > Let's plumb it into the newly created HDMI connector.
> >
> > Reviewed-by: Dave Stevenson
> > Acked-by: Pekka Paalanen
> > Reviewed-by: Sebastian Wick
> > Signed-off-by
On Thu, 7 Mar 2024 14:02:33 +0530
Nemesa Garg wrote:
> This allows the user to set the intensity
> so as to get the sharpness effect.
>
> It is useful in scenario when the output is blurry
> and user want to sharpen the pixels.
>
> Signed-off-by: Nemesa Garg
> ---
>
On Wed, 6 Mar 2024 18:29:53 +0100
Louis Chauvet wrote:
> [...]
>
> > > > > > > +++ b/drivers/gpu/drm/vkms/vkms_formats.c
> > > > > > > @@ -9,6 +9,17 @@
> > > > > > >
> > > > > > > #include "vkms_formats.h"
> > > > > > >
> > > > > > > +/**
> > > > > > > + * packed_pixels_offset() - Get the
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, 5 Mar 2024 14:51:49 +0100
> > Sebastian Wick wrote:
> >
> > > The initial idea of the Colorspace prop was that this maps 1:1 t
e encoding on the wire
> - * (RGB or YCbCr), drivers are free to pick the appropriate
> - * variant, regardless of what userspace selects. E.g., if
> - * BT2020_RGB is selected by userspace a driver will pick
> - * BT2020_YCC if the encoding on the wire is YUV444 or YUV420.
>
On Mon, 4 Mar 2024 18:45:08 +0100
Sebastian Wick wrote:
> The initial idea of the Colorspace prop was that this maps 1:1 to
> InfoFrames/SDP but KMS does not give user space enough information nor
> control over the output format to figure out which variants can be used
> for a given KMS
On Mon, 4 Mar 2024 16:28:33 +0100
Louis Chauvet wrote:
> Le 29/02/24 - 12:21, Pekka Paalanen a écrit :
> > On Tue, 27 Feb 2024 16:02:09 +0100
> > Louis Chauvet wrote:
> >
> > > [...]
> > >
> > > > > -static void
On Mon, 4 Mar 2024 16:28:32 +0100
Louis Chauvet wrote:
> Le 29/02/24 - 11:07, Pekka Paalanen a écrit :
> > On Tue, 27 Feb 2024 16:02:13 +0100
> > Louis Chauvet wrote:
> >
> > > Le 26/02/24 - 13:36, Pekka Paalanen a écrit :
> > > > On Fri, 23 Feb
On Mon, 4 Mar 2024 16:28:30 +0100
Louis Chauvet wrote:
> Le 29/02/24 - 10:48, Pekka Paalanen a écrit :
> > On Tue, 27 Feb 2024 16:02:10 +0100
> > Louis Chauvet wrote:
> >
> > > [...]
> > >
> > > > > diff --git a/drivers/gpu/drm
On Fri, 1 Mar 2024 13:12:02 +0100
Maxime Ripard wrote:
> On Fri, Mar 01, 2024 at 12:29:41PM +0100, Sebastian Wick wrote:
> > On Fri, Mar 01, 2024 at 11:30:56AM +0100, Maxime Ripard wrote:
> > > On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote:
> > > > > @@ -1708,6 +1731,39 @@
On Thu, 29 Feb 2024 14:57:06 -0300
Arthur Grillo wrote:
> On 29/02/24 09:12, Pekka Paalanen wrote:
> > On Wed, 28 Feb 2024 22:52:09 -0300
> > Arthur Grillo wrote:
> >
> >> On 27/02/24 17:01, Arthur Grillo wrote:
> >>>
> >>>
> >&g
On Tue, 27 Feb 2024 15:47:08 -0300
Arthur Grillo wrote:
> On 27/02/24 12:02, Louis Chauvet wrote:
> > Le 26/02/24 - 10:07, Arthur Grillo a écrit :
> >>
> >>
> >> On 26/02/24 05:46, Louis Chauvet wrote:
> >>> Add some documentation on pixel conversion functions.
> >>> Update of outdated
On Tue, 27 Feb 2024 16:02:10 +0100
Louis Chauvet wrote:
> (same as for PATCHv2 6/9, I took the patch from Arthur with no
> modifications)
>
> Le 26/02/24 - 14:23, Pekka Paalanen a écrit :
> > On Fri, 23 Feb 2024 12:37:27 +0100
> > Louis Chauvet wrote:
> >
ur have an
> >> opinion on it, I took his patch as a "black box" (I did not want to
> >> break (and debug) it).
> >>
> >> Le 26/02/24 - 14:19, Pekka Paalanen a écrit :
> >>> On Fri, 23 Feb 2024 12:37:26 +0100
> >>> Louis Chauvet
On Tue, 27 Feb 2024 16:02:09 +0100
Louis Chauvet wrote:
> [...]
>
> > > -static void pre_mul_alpha_blend(struct vkms_frame_info *frame_info,
> > > - struct line_buffer *stage_buffer,
> > > - struct line_buffer *output_buffer)
> > > +static void
On Tue, 27 Feb 2024 16:02:13 +0100
Louis Chauvet wrote:
> Le 26/02/24 - 13:36, Pekka Paalanen a écrit :
> > On Fri, 23 Feb 2024 12:37:24 +0100
> > Louis Chauvet wrote:
> >
> > > Introduce two typedefs: pixel_read_t and pixel_write_t. It allows the
> &g
On Tue, 27 Feb 2024 16:02:10 +0100
Louis Chauvet wrote:
> [...]
>
> > > diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
> > > b/drivers/gpu/drm/vkms/vkms_formats.c
> > > index 172830a3936a..cb7a49b7c8e7 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_formats.c
> > > +++
On Tue, 27 Feb 2024 09:29:58 -0300
Arthur Grillo wrote:
> On 27/02/24 08:55, Pekka Paalanen wrote:
> > On Tue, 27 Feb 2024 08:44:52 -0300
> > Arthur Grillo wrote:
> >
> >> On 27/02/24 06:19, Pekka Paalanen wrote:
> >>> On Mon, 26 Feb 2024
On Tue, 27 Feb 2024 08:44:52 -0300
Arthur Grillo wrote:
> On 27/02/24 06:19, Pekka Paalanen wrote:
> > On Mon, 26 Feb 2024 17:42:11 -0300
> > Arthur Grillo wrote:
> >
> >> Now that we have a defined benchmark for testing the driver, add
> >> documenta
On Mon, 26 Feb 2024 17:23:24 +
Dave Stevenson wrote:
> Hi Pekka
>
> Sorry for the slight delay in replying.
>
> On Mon, 26 Feb 2024 at 15:11, Pekka Paalanen
> wrote:
> >
> > On Mon, 26 Feb 2024 15:10:45 +0100
> > Maxime Ripard wrote:
> >
> &
form/vkms"
> ./build/benchmarks/kms_fb_stress
Do people need to run both commands?
Anyway, a good idea.
Acked-by: Pekka Paalanen
Thanks,
pq
> +
> TODO
>
>
>
> ---
> base-commit: eeb8e8d9f124f279e80ae679f4ba6e822ce4f95f
> change-id: 20240226-bench-vkms-5b8b7aab255e
>
> Best regards,
pgpCoHBpRV85Q.pgp
Description: OpenPGP digital signature
On Mon, 26 Feb 2024 15:10:45 +0100
Maxime Ripard wrote:
> Hi Pekka,
>
> On Wed, Feb 21, 2024 at 11:07:51AM +0200, Pekka Paalanen wrote:
> > On Fri, 16 Feb 2024 18:48:55 +
> > Dave Stevenson wrote:
> >
> > > From: Nick Hollinghur
On Mon, 26 Feb 2024 09:46:30 +0100
Louis Chauvet wrote:
> This patchset is the second version of [1]. It is almost a complete
> rewrite to use a line-by-line algorithm for the composition.
> It can be divided in three parts:
> - PATCH 1 to 4: no functional change is intended, only some
On Fri, 23 Feb 2024 12:37:27 +0100
Louis Chauvet wrote:
> From: Arthur Grillo
>
> Create range and encoding properties. This should be noop, as none of
> the conversion functions need those properties.
None of the conversion function needs this? How can one say so?
The previous patch is
On Fri, 23 Feb 2024 12:37:26 +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 matrices of each encoding and
On Fri, 23 Feb 2024 12:37:25 +0100
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 focussed on readability of the code.
>
> Line-by-line composition was
On Fri, 23 Feb 2024 12:37:23 +0100
Louis Chauvet wrote:
> Add some documentation on pixel conversion functions.
> Update of outdated comments for pixel_write functions.
>
> Signed-off-by: Louis Chauvet
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 4 +++
> drivers/gpu/drm/vkms/vkms_drv.h
On Fri, 23 Feb 2024 12:37:24 +0100
Louis Chauvet wrote:
> Introduce two typedefs: pixel_read_t and pixel_write_t. It allows the
> compiler to check if the passed functions take the correct arguments.
> Such typedefs will help ensuring consistency across the code base in
> case of update of these
> (if
> + * limited is selected but the display expects full), or a black screen
> + * (if full is selected but the display expects limited).
> + *
> + * Drivers can set up this property by calling
> + * drm_connector_attach_broadcast_rgb_property().
> + *
> * content type (HDMI specific):
> * Indicates content type setting to be used in HDMI infoframes to indicate
> * content type for the external device, so that it adjusts its display
This piece of doc looks good to me, so
Acked-by: Pekka Paalanen
Thanks,
pq
pgp21dou4D3Xl.pgp
Description: OpenPGP digital signature
On Thu, 22 Feb 2024 18:38:16 +0100
Pavel Machek wrote:
> Hi!
>
> > > > so after more feedback from the OpenRGB maintainers I came up with an
> > > > even
> > > > more generic proposal:
> > > > https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
> > > >
> > >
> > >
On Wed, 21 Feb 2024 23:17:52 +0100
Pavel Machek wrote:
> Hi!
>
> > so after more feedback from the OpenRGB maintainers I came up with an even
> > more generic proposal:
> > https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
>
> > >evaluate-set-command ioctl taking:
> >
onnector type;
>
> - Or we can just prevent the EDID to be exposed to userspace if it's
> built-in.
>
> Or possibly both.
>
> However, the conclusion was that maybe we just don't need the built-in
> EDIDs at all and we should just get rid of them. So here we are.
Sounds go
On Fri, 16 Feb 2024 18:48:55 +
Dave Stevenson wrote:
> From: Nick Hollinghurst
>
> Add this as a value for enum_drm_connector_tv_mode, represented
> by the string "Mono", to generate video with no colour encoding
> or bursts. Define it to have no pedestal (since only NTSC-M calls
> for a
On Mon, 19 Feb 2024 10:34:19 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Pekka Paalanen
> > Sent: Wednesday, February 14, 2024 2:34 PM
> > To: Shankar, Uma
> > Cc: ville.syrj...@linux.intel.com; intel-...@lists.freedesktop.o
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
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 04:28:41 +
"Garg, Nemesa" wrote:
> It is not intel specific and the goal is to have a generic API for
> configuring Sharpness, accessible to various vendors. Intel currently
> offers sharpness support through the Display Engine, while other
> vendors seem to support
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
1 - 100 of 1083 matches
Mail list logo
