linux-kernel - Re: [PATCH v2 7/9] drm/vkms: Add range and encoding properties to pixel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 27 Feb 2024 16:02:10 +0100
From: Louis Chauvet <louis.chauvet@...tlin.com>
To: Pekka Paalanen <pekka.paalanen@...labora.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

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

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.

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



-- 
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com