All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	quic_abhinavk@quicinc.com, contact@emersion.fr,
	laurent.pinchart@ideasonboard.com, sebastian.wick@redhat.com,
	ville.syrjala@linux.intel.com, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	freedreno@lists.freedesktop.org,
	wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH RFC v4 2/7] drm: Introduce pixel_source DRM plane property
Date: Fri, 30 Jun 2023 11:27:08 +0300	[thread overview]
Message-ID: <20230630112708.4d3a08a7@eldfell> (raw)
In-Reply-To: <6e3eec49-f798-ff91-8b4d-417d31089296@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 9973 bytes --]

On Fri, 30 Jun 2023 03:42:28 +0300
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:

> On 30/06/2023 03:25, Jessica Zhang wrote:
> > Add support for pixel_source property to drm_plane and related
> > documentation.
> > 
> > This enum property will allow user to specify a pixel source for the
> > plane. Possible pixel sources will be defined in the
> > drm_plane_pixel_source enum.
> > 
> > The current possible pixel sources are DRM_PLANE_PIXEL_SOURCE_FB and
> > DRM_PLANE_PIXEL_SOURCE_COLOR. The default value is *_SOURCE_FB.  
> 
> I think, this should come before the solid fill property addition. First 
> you tell that there is a possibility to define other pixel sources, then 
> additional sources are defined.

Hi,

that would be logical indeed.

> > 
> > Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com>
> > ---
> >   drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >   drivers/gpu/drm/drm_atomic_uapi.c         |  4 ++
> >   drivers/gpu/drm/drm_blend.c               | 81 +++++++++++++++++++++++++++++++
> >   include/drm/drm_blend.h                   |  2 +
> >   include/drm/drm_plane.h                   | 21 ++++++++
> >   5 files changed, 109 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index fe14be2bd2b2..86fb876efbe6 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -252,6 +252,7 @@ void __drm_atomic_helper_plane_state_reset(struct drm_plane_state *plane_state,
> >   
> >   	plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> >   	plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> > +	plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
> >   
> >   	if (plane_state->solid_fill_blob) {
> >   		drm_property_blob_put(plane_state->solid_fill_blob);
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > index a28b4ee79444..6e59c21af66b 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -596,6 +596,8 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
> >   		drm_property_blob_put(solid_fill);
> >   
> >   		return ret;
> > +	} else if (property == plane->pixel_source_property) {
> > +		state->pixel_source = val;
> >   	} else if (property == plane->alpha_property) {
> >   		state->alpha = val;
> >   	} else if (property == plane->blend_mode_property) {  
> 
> I think, it was pointed out in the discussion that drm_mode_setplane() 
> (a pre-atomic IOCTL to turn the plane on and off) should also reset 
> pixel_source to FB.
> 
> > @@ -671,6 +673,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> >   	} else if (property == plane->solid_fill_property) {
> >   		*val = state->solid_fill_blob ?
> >   			state->solid_fill_blob->base.id : 0;
> > +	} else if (property == plane->pixel_source_property) {
> > +		*val = state->pixel_source;
> >   	} else if (property == plane->alpha_property) {
> >   		*val = state->alpha;
> >   	} else if (property == plane->blend_mode_property) {
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index 38c3c5d6453a..8c100a957ee2 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -189,6 +189,18 @@
> >    *	solid_fill is set up with drm_plane_create_solid_fill_property(). It
> >    *	contains pixel data that drivers can use to fill a plane.
> >    *
> > + * pixel_source:
> > + *	pixel_source is set up with drm_plane_create_pixel_source_property().
> > + *	It is used to toggle the source of pixel data for the plane.

Other sources than the selected one are ignored?

> > + *
> > + *	Possible values:

Wouldn't hurt to explicitly mention here that this is an enum.

> > + *
> > + *	"FB":
> > + *		Framebuffer source
> > + *
> > + *	"COLOR":
> > + *		solid_fill source

I think these two should be more explicit. Framebuffer source is the
usual source from the property "FB_ID". Solid fill source comes from
the property "solid_fill".

Why "COLOR" and not, say, "SOLID_FILL"?

> > + *
> >    * Note that all the property extensions described here apply either to the
> >    * plane or the CRTC (e.g. for the background color, which currently is not
> >    * exposed and assumed to be black).
> > @@ -648,3 +660,72 @@ int drm_plane_create_solid_fill_property(struct drm_plane *plane)
> >   	return 0;
> >   }
> >   EXPORT_SYMBOL(drm_plane_create_solid_fill_property);
> > +
> > +/**
> > + * drm_plane_create_pixel_source_property - create a new pixel source property
> > + * @plane: drm plane
> > + * @supported_sources: bitmask of supported pixel_sources for the driver (NOT
> > + *                     including DRM_PLANE_PIXEL_SOURCE_FB, as it will be supported
> > + *                     by default).  
> 
> I'd say this is too strong. I'd suggest either renaming this to 
> extra_sources (mentioning that FB is enabled for all the planes) or 
> allowing any source bitmask (mentioning that FB should be enabled by the 
> caller, unless there is a good reason not to do so).

Right. I don't see any problem with having planes of type OVERLAY that
support only solid_fill and no FB. Planes of type PRIMARY and CURSOR I
would expect to always support at least FB.

Atomic userspace is prepared to have an OVERLAY plane fail for any
arbitrary reason. Legacy userspace probably should not ever see a plane
that does not support FB.

> > + *
> > + * This creates a new property describing the current source of pixel data for the
> > + * plane.
> > + *
> > + * The property is exposed to userspace as an enumeration property called
> > + * "pixel_source" and has the following enumeration values:
> > + *
> > + * "FB":
> > + *	Framebuffer pixel source
> > + *
> > + * "COLOR":
> > + *	Solid fill color pixel source
> > + *
> > + * Returns:
> > + * Zero on success, negative errno on failure.
> > + */
> > +int drm_plane_create_pixel_source_property(struct drm_plane *plane,
> > +					   unsigned int supported_sources)
> > +{
> > +	struct drm_device *dev = plane->dev;
> > +	struct drm_property *prop;
> > +	const struct drm_prop_enum_list enum_list[] = {
> > +		{ DRM_PLANE_PIXEL_SOURCE_FB, "FB" },
> > +		{ DRM_PLANE_PIXEL_SOURCE_COLOR, "COLOR" },
> > +	};
> > +	unsigned int valid_source_mask = BIT(DRM_PLANE_PIXEL_SOURCE_FB) |
> > +				       BIT(DRM_PLANE_PIXEL_SOURCE_COLOR);  
> 
> 
> static const?
> 
> > +	int i;
> > +
> > +	/* FB is supported by default */
> > +	supported_sources |= BIT(DRM_PLANE_PIXEL_SOURCE_FB);
> > +
> > +	if (WARN_ON(supported_sources & ~valid_source_mask))
> > +		return -EINVAL;
> > +
> > +	prop = drm_property_create(dev, DRM_MODE_PROP_ENUM, "pixel_source",

Shouldn't this be an atomic prop?


> > +			hweight32(supported_sources));
> > +
> > +	if (!prop)
> > +		return -ENOMEM;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(enum_list); i++) {
> > +		int ret;
> > +
> > +		if (!(BIT(enum_list[i].type) & supported_sources))  
> 
> test_bit?
> 
> > +			continue;
> > +
> > +		ret = drm_property_add_enum(prop, enum_list[i].type, enum_list[i].name);
> > +  
> 
> No need for an empty line in such cases. Please drop it.
> 
> > +		if (ret) {
> > +			drm_property_destroy(dev, prop);
> > +
> > +			return ret;
> > +		}
> > +	}
> > +
> > +	drm_object_attach_property(&plane->base, prop, DRM_PLANE_PIXEL_SOURCE_FB);
> > +	plane->pixel_source_property = prop;
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(drm_plane_create_pixel_source_property);
> > diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
> > index 0338a860b9c8..31af7cfa5b1b 100644
> > --- a/include/drm/drm_blend.h
> > +++ b/include/drm/drm_blend.h
> > @@ -59,4 +59,6 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
> >   int drm_plane_create_blend_mode_property(struct drm_plane *plane,
> >   					 unsigned int supported_modes);
> >   int drm_plane_create_solid_fill_property(struct drm_plane *plane);
> > +int drm_plane_create_pixel_source_property(struct drm_plane *plane,
> > +					   unsigned int supported_sources);
> >   #endif
> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> > index f6ab313cb83e..73fb6cf8a5d9 100644
> > --- a/include/drm/drm_plane.h
> > +++ b/include/drm/drm_plane.h
> > @@ -59,6 +59,12 @@ struct drm_solid_fill {
> >   	uint32_t b;
> >   };
> >   
> > +enum drm_plane_pixel_source {
> > +	DRM_PLANE_PIXEL_SOURCE_FB,
> > +	DRM_PLANE_PIXEL_SOURCE_COLOR,
> > +	DRM_PLANE_PIXEL_SOURCE_MAX
> > +};

Just to be very clear that I'm not confusing you with my comment about
UAPI headers in the previous patch, this enum is already in a good
place. It does not belong in a UAPI header, because userspace
recognises enum values by the name string.


Thanks,
pq

> > +
> >   /**
> >    * struct drm_plane_state - mutable plane state
> >    *
> > @@ -152,6 +158,14 @@ struct drm_plane_state {
> >   	 */
> >   	struct drm_solid_fill solid_fill;
> >   
> > +	/*
> > +	 * @pixel_source:
> > +	 *
> > +	 * Source of pixel information for the plane. See
> > +	 * drm_plane_create_pixel_source_property() for more details.
> > +	 */
> > +	enum drm_plane_pixel_source pixel_source;
> > +
> >   	/**
> >   	 * @alpha:
> >   	 * Opacity of the plane with 0 as completely transparent and 0xffff as
> > @@ -742,6 +756,13 @@ struct drm_plane {
> >   	 */
> >   	struct drm_property *solid_fill_property;
> >   
> > +	/*
> > +	 * @pixel_source_property:
> > +	 * Optional pixel_source property for this plane. See
> > +	 * drm_plane_create_pixel_source_property().
> > +	 */
> > +	struct drm_property *pixel_source_property;
> > +
> >   	/**
> >   	 * @alpha_property:
> >   	 * Optional alpha property for this plane. See
> >   
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
	sebastian.wick@redhat.com,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Sean Paul <sean@poorly.run>,
	dri-devel@lists.freedesktop.org, quic_abhinavk@quicinc.com,
	Maxime Ripard <mripard@kernel.org>,
	linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH RFC v4 2/7] drm: Introduce pixel_source DRM plane property
Date: Fri, 30 Jun 2023 11:27:08 +0300	[thread overview]
Message-ID: <20230630112708.4d3a08a7@eldfell> (raw)
In-Reply-To: <6e3eec49-f798-ff91-8b4d-417d31089296@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 9973 bytes --]

On Fri, 30 Jun 2023 03:42:28 +0300
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:

> On 30/06/2023 03:25, Jessica Zhang wrote:
> > Add support for pixel_source property to drm_plane and related
> > documentation.
> > 
> > This enum property will allow user to specify a pixel source for the
> > plane. Possible pixel sources will be defined in the
> > drm_plane_pixel_source enum.
> > 
> > The current possible pixel sources are DRM_PLANE_PIXEL_SOURCE_FB and
> > DRM_PLANE_PIXEL_SOURCE_COLOR. The default value is *_SOURCE_FB.  
> 
> I think, this should come before the solid fill property addition. First 
> you tell that there is a possibility to define other pixel sources, then 
> additional sources are defined.

Hi,

that would be logical indeed.

> > 
> > Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com>
> > ---
> >   drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >   drivers/gpu/drm/drm_atomic_uapi.c         |  4 ++
> >   drivers/gpu/drm/drm_blend.c               | 81 +++++++++++++++++++++++++++++++
> >   include/drm/drm_blend.h                   |  2 +
> >   include/drm/drm_plane.h                   | 21 ++++++++
> >   5 files changed, 109 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index fe14be2bd2b2..86fb876efbe6 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -252,6 +252,7 @@ void __drm_atomic_helper_plane_state_reset(struct drm_plane_state *plane_state,
> >   
> >   	plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> >   	plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> > +	plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
> >   
> >   	if (plane_state->solid_fill_blob) {
> >   		drm_property_blob_put(plane_state->solid_fill_blob);
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > index a28b4ee79444..6e59c21af66b 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -596,6 +596,8 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
> >   		drm_property_blob_put(solid_fill);
> >   
> >   		return ret;
> > +	} else if (property == plane->pixel_source_property) {
> > +		state->pixel_source = val;
> >   	} else if (property == plane->alpha_property) {
> >   		state->alpha = val;
> >   	} else if (property == plane->blend_mode_property) {  
> 
> I think, it was pointed out in the discussion that drm_mode_setplane() 
> (a pre-atomic IOCTL to turn the plane on and off) should also reset 
> pixel_source to FB.
> 
> > @@ -671,6 +673,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> >   	} else if (property == plane->solid_fill_property) {
> >   		*val = state->solid_fill_blob ?
> >   			state->solid_fill_blob->base.id : 0;
> > +	} else if (property == plane->pixel_source_property) {
> > +		*val = state->pixel_source;
> >   	} else if (property == plane->alpha_property) {
> >   		*val = state->alpha;
> >   	} else if (property == plane->blend_mode_property) {
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index 38c3c5d6453a..8c100a957ee2 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -189,6 +189,18 @@
> >    *	solid_fill is set up with drm_plane_create_solid_fill_property(). It
> >    *	contains pixel data that drivers can use to fill a plane.
> >    *
> > + * pixel_source:
> > + *	pixel_source is set up with drm_plane_create_pixel_source_property().
> > + *	It is used to toggle the source of pixel data for the plane.

Other sources than the selected one are ignored?

> > + *
> > + *	Possible values:

Wouldn't hurt to explicitly mention here that this is an enum.

> > + *
> > + *	"FB":
> > + *		Framebuffer source
> > + *
> > + *	"COLOR":
> > + *		solid_fill source

I think these two should be more explicit. Framebuffer source is the
usual source from the property "FB_ID". Solid fill source comes from
the property "solid_fill".

Why "COLOR" and not, say, "SOLID_FILL"?

> > + *
> >    * Note that all the property extensions described here apply either to the
> >    * plane or the CRTC (e.g. for the background color, which currently is not
> >    * exposed and assumed to be black).
> > @@ -648,3 +660,72 @@ int drm_plane_create_solid_fill_property(struct drm_plane *plane)
> >   	return 0;
> >   }
> >   EXPORT_SYMBOL(drm_plane_create_solid_fill_property);
> > +
> > +/**
> > + * drm_plane_create_pixel_source_property - create a new pixel source property
> > + * @plane: drm plane
> > + * @supported_sources: bitmask of supported pixel_sources for the driver (NOT
> > + *                     including DRM_PLANE_PIXEL_SOURCE_FB, as it will be supported
> > + *                     by default).  
> 
> I'd say this is too strong. I'd suggest either renaming this to 
> extra_sources (mentioning that FB is enabled for all the planes) or 
> allowing any source bitmask (mentioning that FB should be enabled by the 
> caller, unless there is a good reason not to do so).

Right. I don't see any problem with having planes of type OVERLAY that
support only solid_fill and no FB. Planes of type PRIMARY and CURSOR I
would expect to always support at least FB.

Atomic userspace is prepared to have an OVERLAY plane fail for any
arbitrary reason. Legacy userspace probably should not ever see a plane
that does not support FB.

> > + *
> > + * This creates a new property describing the current source of pixel data for the
> > + * plane.
> > + *
> > + * The property is exposed to userspace as an enumeration property called
> > + * "pixel_source" and has the following enumeration values:
> > + *
> > + * "FB":
> > + *	Framebuffer pixel source
> > + *
> > + * "COLOR":
> > + *	Solid fill color pixel source
> > + *
> > + * Returns:
> > + * Zero on success, negative errno on failure.
> > + */
> > +int drm_plane_create_pixel_source_property(struct drm_plane *plane,
> > +					   unsigned int supported_sources)
> > +{
> > +	struct drm_device *dev = plane->dev;
> > +	struct drm_property *prop;
> > +	const struct drm_prop_enum_list enum_list[] = {
> > +		{ DRM_PLANE_PIXEL_SOURCE_FB, "FB" },
> > +		{ DRM_PLANE_PIXEL_SOURCE_COLOR, "COLOR" },
> > +	};
> > +	unsigned int valid_source_mask = BIT(DRM_PLANE_PIXEL_SOURCE_FB) |
> > +				       BIT(DRM_PLANE_PIXEL_SOURCE_COLOR);  
> 
> 
> static const?
> 
> > +	int i;
> > +
> > +	/* FB is supported by default */
> > +	supported_sources |= BIT(DRM_PLANE_PIXEL_SOURCE_FB);
> > +
> > +	if (WARN_ON(supported_sources & ~valid_source_mask))
> > +		return -EINVAL;
> > +
> > +	prop = drm_property_create(dev, DRM_MODE_PROP_ENUM, "pixel_source",

Shouldn't this be an atomic prop?


> > +			hweight32(supported_sources));
> > +
> > +	if (!prop)
> > +		return -ENOMEM;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(enum_list); i++) {
> > +		int ret;
> > +
> > +		if (!(BIT(enum_list[i].type) & supported_sources))  
> 
> test_bit?
> 
> > +			continue;
> > +
> > +		ret = drm_property_add_enum(prop, enum_list[i].type, enum_list[i].name);
> > +  
> 
> No need for an empty line in such cases. Please drop it.
> 
> > +		if (ret) {
> > +			drm_property_destroy(dev, prop);
> > +
> > +			return ret;
> > +		}
> > +	}
> > +
> > +	drm_object_attach_property(&plane->base, prop, DRM_PLANE_PIXEL_SOURCE_FB);
> > +	plane->pixel_source_property = prop;
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(drm_plane_create_pixel_source_property);
> > diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
> > index 0338a860b9c8..31af7cfa5b1b 100644
> > --- a/include/drm/drm_blend.h
> > +++ b/include/drm/drm_blend.h
> > @@ -59,4 +59,6 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
> >   int drm_plane_create_blend_mode_property(struct drm_plane *plane,
> >   					 unsigned int supported_modes);
> >   int drm_plane_create_solid_fill_property(struct drm_plane *plane);
> > +int drm_plane_create_pixel_source_property(struct drm_plane *plane,
> > +					   unsigned int supported_sources);
> >   #endif
> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> > index f6ab313cb83e..73fb6cf8a5d9 100644
> > --- a/include/drm/drm_plane.h
> > +++ b/include/drm/drm_plane.h
> > @@ -59,6 +59,12 @@ struct drm_solid_fill {
> >   	uint32_t b;
> >   };
> >   
> > +enum drm_plane_pixel_source {
> > +	DRM_PLANE_PIXEL_SOURCE_FB,
> > +	DRM_PLANE_PIXEL_SOURCE_COLOR,
> > +	DRM_PLANE_PIXEL_SOURCE_MAX
> > +};

Just to be very clear that I'm not confusing you with my comment about
UAPI headers in the previous patch, this enum is already in a good
place. It does not belong in a UAPI header, because userspace
recognises enum values by the name string.


Thanks,
pq

> > +
> >   /**
> >    * struct drm_plane_state - mutable plane state
> >    *
> > @@ -152,6 +158,14 @@ struct drm_plane_state {
> >   	 */
> >   	struct drm_solid_fill solid_fill;
> >   
> > +	/*
> > +	 * @pixel_source:
> > +	 *
> > +	 * Source of pixel information for the plane. See
> > +	 * drm_plane_create_pixel_source_property() for more details.
> > +	 */
> > +	enum drm_plane_pixel_source pixel_source;
> > +
> >   	/**
> >   	 * @alpha:
> >   	 * Opacity of the plane with 0 as completely transparent and 0xffff as
> > @@ -742,6 +756,13 @@ struct drm_plane {
> >   	 */
> >   	struct drm_property *solid_fill_property;
> >   
> > +	/*
> > +	 * @pixel_source_property:
> > +	 * Optional pixel_source property for this plane. See
> > +	 * drm_plane_create_pixel_source_property().
> > +	 */
> > +	struct drm_property *pixel_source_property;
> > +
> >   	/**
> >   	 * @alpha_property:
> >   	 * Optional alpha property for this plane. See
> >   
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-06-30  8:27 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-30  0:24 [PATCH RFC v4 0/7] Support for Solid Fill Planes Jessica Zhang
2023-06-30  0:24 ` Jessica Zhang
2023-06-30  0:25 ` [PATCH RFC v4 1/7] drm: Introduce solid fill DRM plane property Jessica Zhang
2023-06-30  0:25   ` Jessica Zhang
2023-06-30  8:27   ` Pekka Paalanen
2023-06-30  8:27     ` Pekka Paalanen
2023-07-10 23:12     ` [Freedreno] " Jessica Zhang
2023-07-10 23:12       ` Jessica Zhang
2023-07-11  7:42       ` Pekka Paalanen
2023-07-11  7:42         ` Pekka Paalanen
2023-07-11 21:47         ` Jessica Zhang
2023-07-11 21:47           ` Jessica Zhang
2023-06-30 10:33   ` Dmitry Baryshkov
2023-06-30 10:33     ` Dmitry Baryshkov
2023-06-30 17:54     ` Jessica Zhang
2023-06-30 17:54       ` Jessica Zhang
2023-06-30  0:25 ` [PATCH RFC v4 2/7] drm: Introduce pixel_source " Jessica Zhang
2023-06-30  0:25   ` Jessica Zhang
2023-06-30  0:42   ` Dmitry Baryshkov
2023-06-30  0:42     ` Dmitry Baryshkov
2023-06-30  8:27     ` Pekka Paalanen [this message]
2023-06-30  8:27       ` Pekka Paalanen
2023-07-10 19:51       ` Jessica Zhang
2023-07-10 19:51         ` Jessica Zhang
2023-07-10 20:11         ` Dmitry Baryshkov
2023-07-10 20:11           ` Dmitry Baryshkov
2023-07-11 22:07           ` Jessica Zhang
2023-07-11 22:07             ` Jessica Zhang
2023-07-11 22:19             ` Dmitry Baryshkov
2023-07-11 22:19               ` Dmitry Baryshkov
2023-07-11 22:42               ` Abhinav Kumar
2023-07-11 22:42                 ` Abhinav Kumar
2023-07-11 23:00                 ` Dmitry Baryshkov
2023-07-11 23:00                   ` Dmitry Baryshkov
2023-07-12  7:35                 ` Pekka Paalanen
2023-07-12  7:35                   ` Pekka Paalanen
2023-06-30 14:43   ` Sebastian Wick
2023-06-30 14:43     ` Sebastian Wick
2023-06-30 21:27     ` Jessica Zhang
2023-06-30 21:27       ` Jessica Zhang
2023-07-03 11:49       ` Sebastian Wick
2023-07-03 11:49         ` Sebastian Wick
2023-06-30  0:25 ` [PATCH RFC v4 3/7] drm/atomic: Move framebuffer checks to helper Jessica Zhang
2023-06-30  0:25   ` Jessica Zhang
2023-06-30  0:43   ` Dmitry Baryshkov
2023-06-30  0:43     ` Dmitry Baryshkov
2023-06-30 17:59     ` Jessica Zhang
2023-06-30 17:59       ` Jessica Zhang
2023-06-30  0:25 ` [PATCH RFC v4 4/7] drm/atomic: Loosen FB atomic checks Jessica Zhang
2023-06-30  0:25   ` Jessica Zhang
2023-06-30  0:48   ` Dmitry Baryshkov
2023-06-30  0:48     ` Dmitry Baryshkov
2023-06-30 23:41     ` Jessica Zhang
2023-06-30 23:41       ` Jessica Zhang
2023-06-30  0:25 ` [PATCH RFC v4 5/7] drm/msm/dpu: Add solid fill and pixel source properties Jessica Zhang
2023-06-30  0:25   ` Jessica Zhang
2023-06-30  0:49   ` Dmitry Baryshkov
2023-06-30  0:49     ` Dmitry Baryshkov
2023-06-30 23:41     ` Jessica Zhang
2023-06-30 23:41       ` Jessica Zhang
2023-06-30  0:25 ` [PATCH RFC v4 6/7] drm/msm/dpu: Allow NULL FBs in atomic commit Jessica Zhang
2023-06-30  0:25   ` Jessica Zhang
2023-06-30  0:52   ` Dmitry Baryshkov
2023-06-30  0:52     ` Dmitry Baryshkov
2023-06-30  8:21     ` Pekka Paalanen
2023-06-30  8:21       ` Pekka Paalanen
2023-07-01  1:14       ` Jessica Zhang
2023-07-01  1:14         ` Jessica Zhang
2023-06-30  0:25 ` [PATCH RFC v4 7/7] drm/msm/dpu: Use DRM solid_fill property Jessica Zhang
2023-06-30  0:25   ` Jessica Zhang
2023-06-30  0:59   ` Dmitry Baryshkov
2023-06-30  0:59     ` Dmitry Baryshkov
2023-07-01  1:26     ` Jessica Zhang
2023-07-01  1:26       ` Jessica Zhang
2023-06-30  8:26   ` Pekka Paalanen
2023-06-30  8:26     ` Pekka Paalanen
2023-07-03  7:42     ` Pekka Paalanen
2023-07-03  7:42       ` Pekka Paalanen
2023-07-12  0:01       ` Jessica Zhang
2023-07-12  0:01         ` Jessica Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230630112708.4d3a08a7@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=airlied@gmail.com \
    --cc=contact@emersion.fr \
    --cc=daniel@ffwll.ch \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marijn.suijten@somainline.org \
    --cc=mripard@kernel.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=quic_jesszhan@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --cc=sebastian.wick@redhat.com \
    --cc=tzimmermann@suse.de \
    --cc=ville.syrjala@linux.intel.com \
    --cc=wayland-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.