[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240229142426.274ae199.pekka.paalanen@collabora.com>
Date: Thu, 29 Feb 2024 14:24:26 +0200
From: Pekka Paalanen <pekka.paalanen@...labora.com>
To: Louis Chauvet <louis.chauvet@...tlin.com>
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@...il.com>, Melissa Wen
<melissa.srw@...il.com>, Maíra Canal
<mairacanal@...eup.net>, Haneen Mohammed <hamohammed.sa@...il.com>, Daniel
Vetter <daniel@...ll.ch>, Maarten Lankhorst
<maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
arthurgrillo@...eup.net, Jonathan Corbet <corbet@....net>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
jeremie.dautheribes@...tlin.com, miquel.raynal@...tlin.com,
thomas.petazzoni@...tlin.com
Subject: Re: [PATCH v2 7/9] drm/vkms: Add range and encoding properties to
pixel_read function
On Tue, 27 Feb 2024 16:02:10 +0100
Louis Chauvet <louis.chauvet@...tlin.com> 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 <louis.chauvet@...tlin.com> wrote:
> >
> > > From: Arthur Grillo <arthurgrillo@...eup.net>
> > >
> > > 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 making use of them already, AFAICT?
>
> It's my fault, I mixed the commits (in Arthur's series, "Add range..." was
> before "Add YUV support"), but for me it makes no sens to have the color
> property without the support in the driver.
Ah, so if there was no YUV support, these properties would never affect
anything. Ok, I see where that is coming from.
>
> Maybe it's better just to merge "Add range..." with "Add YUV support"?
>
> > How is this a noop? Is it not exposing new UAPI from VKMS?
>
> It's not a no-op from userspace, but from the driver side, yes.
If it all is already hooked up and handled in the driver, then say just
that?
"Now that the driver internally handles these quantization ranges and YUV
encoding matrices, expose the UAPI for setting them."
And fix the commit summary line too, nothing "pixel_read" here.
Thanks,
pq
>
> Kind regards,
> Louis Chauvet
>
> > Thanks,
> > pq
> >
> > >
> > > Signed-off-by: Arthur Grillo <arthurgrillo@...eup.net>
> > > [Louis Chauvet: retained only relevant parts]
> > > Signed-off-by: Louis Chauvet <louis.chauvet@...tlin.com>
> > > ---
> > > drivers/gpu/drm/vkms/vkms_plane.c | 9 +++++++++
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c
> > > index 427ca67c60ce..95dfde297377 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_plane.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> > > @@ -228,5 +228,14 @@ struct vkms_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> > > drm_plane_create_rotation_property(&plane->base, DRM_MODE_ROTATE_0,
> > > DRM_MODE_ROTATE_MASK | DRM_MODE_REFLECT_MASK);
> > >
> > > + drm_plane_create_color_properties(&plane->base,
> > > + BIT(DRM_COLOR_YCBCR_BT601) |
> > > + BIT(DRM_COLOR_YCBCR_BT709) |
> > > + BIT(DRM_COLOR_YCBCR_BT2020),
> > > + BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
> > > + BIT(DRM_COLOR_YCBCR_FULL_RANGE),
> > > + DRM_COLOR_YCBCR_BT601,
> > > + DRM_COLOR_YCBCR_FULL_RANGE);
> > > +
> > > return plane;
> > > }
> > >
> >
>
>
>
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists