All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Maíra Canal" <mcanal@igalia.com>
Cc: "André Almeida" <andrealmeid@igalia.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Melissa Wen" <mwen@igalia.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/gem: Check for valid formats
Date: Thu, 5 Jan 2023 16:26:32 +0100	[thread overview]
Message-ID: <Y7bsKFCIOgauVbII@phenom.ffwll.local> (raw)
In-Reply-To: <20230103125322.855089-1-mcanal@igalia.com>

On Tue, Jan 03, 2023 at 09:53:23AM -0300, Maíra Canal wrote:
> Currently, drm_gem_fb_create() doesn't check if the pixel format is
> supported, which can lead to the acceptance of invalid pixel formats
> e.g. the acceptance of invalid modifiers. Therefore, add a check for
> valid formats on drm_gem_fb_create().
> 
> Moreover, note that this check is only valid for atomic drivers,
> because, for non-atomic drivers, checking drm_any_plane_has_format() is
> not possible since the format list for the primary plane is fake, and
> we'd therefor reject valid formats.
> 
> Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maíra Canal <mcanal@igalia.com>

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

I think to really make sure we have consensus it'd be good to extend this
to a series which removes all the callers to drm_any_plane_has_format()
from the various drivers, and then unexports that helper. That way your
series here will have more eyes on it :-)
-Daniel

> ---
>  Documentation/gpu/todo.rst                   | 7 ++-----
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 9 +++++++++
>  2 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 1f8a5ebe188e..68bdafa0284f 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -276,11 +276,8 @@ Various hold-ups:
>  - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb
>    setup code can't be deleted.
>  
> -- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For
> -  atomic drivers we could check for valid formats by calling
> -  drm_plane_check_pixel_format() against all planes, and pass if any plane
> -  supports the format. For non-atomic that's not possible since like the format
> -  list for the primary plane is fake and we'd therefor reject valid formats.
> +- Need to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for
> +  valid formats for atomic drivers.
>  
>  - Many drivers subclass drm_framebuffer, we'd need a embedding compatible
>    version of the varios drm_gem_fb_create functions. Maybe called
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index e93533b86037..b8a615a138cd 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -9,6 +9,7 @@
>  #include <linux/module.h>
>  
>  #include <drm/drm_damage_helper.h>
> +#include <drm/drm_drv.h>
>  #include <drm/drm_fourcc.h>
>  #include <drm/drm_framebuffer.h>
>  #include <drm/drm_gem.h>
> @@ -164,6 +165,14 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev,
>  		return -EINVAL;
>  	}
>  
> +	if (drm_drv_uses_atomic_modeset(dev) &&
> +	    !drm_any_plane_has_format(dev, mode_cmd->pixel_format,
> +				      mode_cmd->modifier[0])) {
> +		drm_dbg(dev, "Unsupported pixel format %p4cc / modifier 0x%llx\n",
> +			&mode_cmd->pixel_format, mode_cmd->modifier[0]);
> +		return -EINVAL;
> +	}
> +
>  	for (i = 0; i < info->num_planes; i++) {
>  		unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
>  		unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
> -- 
> 2.38.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  parent reply	other threads:[~2023-01-05 15:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-03 12:53 [PATCH] drm/gem: Check for valid formats Maíra Canal
2023-01-03 13:16 ` Thomas Zimmermann
2023-01-05 15:24   ` Daniel Vetter
2023-01-05 15:43     ` Thomas Zimmermann
2023-01-05 15:51       ` Daniel Vetter
2023-01-03 22:46 ` Rob Clark
2023-01-03 23:27   ` Simon Ser
2023-01-04  1:11   ` Maíra Canal
2023-01-04  2:22     ` Rob Clark
2023-01-05 15:26 ` Daniel Vetter [this message]
2023-01-05 17:48   ` Maíra Canal
2023-01-05 18:22     ` Daniel Vetter
2023-01-05 18:30       ` Maíra Canal
2023-01-05 18:36         ` Simon Ser
2023-01-05 18:48           ` Maíra Canal
2023-01-05 18:54             ` Simon Ser
2023-01-05 19:00               ` Maíra Canal
2023-01-05 20:04                 ` Simon Ser
2023-01-06 17:42                   ` Daniel Vetter
2023-01-06  7:10       ` Thomas Zimmermann
2023-01-05 15:59 ` Thomas Zimmermann
  -- strict thread matches above, loose matches on Subject: below --
2023-04-12 14:29 Maíra Canal
2023-04-12 14:53 ` Ville Syrjälä

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=Y7bsKFCIOgauVbII@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=andrealmeid@igalia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mcanal@igalia.com \
    --cc=mwen@igalia.com \
    --cc=tzimmermann@suse.de \
    /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.