From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: [RFC] checking drm_framebuffer against config width/height Date: Wed, 18 Sep 2019 20:30:49 -0700 Message-ID: <09ee01d56e9a$a2739380$e75aba80$@codeaurora.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0831474569==" Return-path: Content-Language: en-us List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: freedreno-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "Freedreno" To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Cc: sean-p7yTbzM4H96eqtR555YLDQ@public.gmane.org, 'Rob Clark' , 'Sean Paul' List-Id: dri-devel@lists.freedesktop.org This is a multipart message in MIME format. --===============0831474569== Content-Type: multipart/alternative; boundary="----=_NextPart_000_09EF_01D56E5F.F61816E0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_09EF_01D56E5F.F61816E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello All, I bumped into the below check [1] enforced in drm_framebuffer creation which checks the requested framebuffer width/height parameters against the drm mode config width/height limits. As I understand, drm_mode_config: min/max width/height indicate the upper and lower bounds of the display panel (drm_connector) resolutions the DRM device can support. But the pixel processing pipeline can apply cropping/scaling transformations on much larger input framebuffers and flip the buffers within the display resolution. Such configurations are very common and the final resolution will be still within drm_mode_config bounds. So I believe the checks should be relaxed / removed from the drm_framebuffer creation api's. If my understanding is incorrect, could somehow explain the motivation behind having these checks here? Thanks and Regards, Jeykumar S. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv ers/gpu/drm/drm_framebuffer.c?h=v5.3#n303 struct drm_framebuffer * drm_internal_framebuffer_create(struct drm_device *dev, const struct drm_mode_fb_cmd2 *r, struct drm_file *file_priv) { /* snip */ if ((config->min_width > r->width) || (r->width > config->max_width)) { DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && <= %d\n", r->width, config->min_width, config->max_width); return ERR_PTR(-EINVAL); } if ((config->min_height > r->height) || (r->height > config->max_height)) { DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d && <= %d\n", r->height, config->min_height, config->max_height); return ERR_PTR(-EINVAL); } /* snip */ } ------=_NextPart_000_09EF_01D56E5F.F61816E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

I bumped into the below check [1] enforced in = drm_framebuffer creation which checks the requested framebuffer = width/height parameters against the drm mode config width/height limits. = As I understand, drm_mode_config: min/max width/height indicate the = upper and lower bounds of the display panel (drm_connector) resolutions = the DRM device can support. But the pixel processing pipeline can apply = cropping/scaling transformations on much larger input framebuffers and = flip the buffers within the display resolution. Such configurations are = very common and the final resolution will be still within = drm_mode_config bounds. So I believe the checks should be relaxed / = removed from the drm_framebuffer creation api’s.

 

If my understanding is = incorrect, could somehow explain the motivation behind having these = checks here?

 

Thanks and Regards,

Jeykumar S.

 

[1] https://git.kerne= l.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/dr= m_framebuffer.c?h=3Dv5.3#n303

 

struct drm_framebuffer *
drm_internal_framebuffer_create=
(struct drm_device *dev,
        &nb=
sp;           &nbs=
p;          const struct drm_mode_fb_cmd2 *r,
        &nb=
sp;           &nbs=
p;          struct drm_file *file_priv)
{

         &= nbsp;           /* snip = */

 

        = if = ((config->min_width > r->width) || (r->width > = config->max_width)) {

         &= nbsp;     DRM_DEBUG_KMS("bad framebuffer width %d, = should be >=3D %d && <=3D %d\n",

         &= nbsp;           &n= bsp;   r->width, config->min_width, = config->max_width);

         &= nbsp;     return = ERR_PTR(-EINVAL);

        = }

        = if = ((config->min_height > r->height) || (r->height > = config->max_height)) {

         &= nbsp;     DRM_DEBUG_KMS("bad framebuffer height %d, = should be >=3D %d && <=3D %d\n",

         &= nbsp;           &n= bsp;   r->height, config->min_height, = config->max_height);

         &= nbsp;     return = ERR_PTR(-EINVAL);

        = }

        /* snip = */

}

 

------=_NextPart_000_09EF_01D56E5F.F61816E0-- --===============0831474569== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJlZWRyZW5v IG1haWxpbmcgbGlzdApGcmVlZHJlbm9AbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWRyZW5v --===============0831474569==--