On Fri, Nov 11, 2011 at 08:24:18AM -0800, Jesse Barnes wrote:
> On Fri, 11 Nov 2011 18:04:04 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> >
> > Make sure the source coordinates stay within the buffer.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > ---
> > drivers/gpu/drm/drm_crtc.c | 23 +++++++++++++++++++++++
> > 1 files changed, 23 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 70f5747..098cc50 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1654,6 +1654,7 @@ int drm_mode_setplane(struct drm_device *dev, void
> > *data,
> > struct drm_crtc *crtc;
> > struct drm_framebuffer *fb;
> > int ret = 0;
> > + unsigned int fb_width, fb_height;
> >
> > if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > return -EINVAL;
> > @@ -1702,6 +1703,28 @@ int drm_mode_setplane(struct drm_device *dev, void
> > *data,
> > }
> > fb = obj_to_fb(obj);
> >
> > + fb_width = fb->width << 16;
> > + fb_height = fb->height << 16;
> > +
> > + /* Make sure source coordinates are inside the fb. */
> > + if (plane_req->src_w > fb_width ||
> > + plane_req->src_x > fb_width - plane_req->src_w ||
> > + plane_req->src_h > fb_height ||
> > + plane_req->src_y > fb_height - plane_req->src_h) {
> > + DRM_DEBUG_KMS("Invalid source coordinates "
> > + "%01u.%06ux%01u.%06u+%01u.%06u+%01u.%06u\n",
> > + plane_req->src_w >> 16,
> > + ((plane_req->src_w & 0xffff) * 15625) >> 10,
> > + plane_req->src_h >> 16,
> > + ((plane_req->src_h & 0xffff) * 15625) >> 10,
> > + plane_req->src_x >> 16,
> > + ((plane_req->src_x & 0xffff) * 15625) >> 10,
> > + plane_req->src_y >> 16,
> > + ((plane_req->src_y & 0xffff) * 15625) >> 10);
> > + ret = -EINVAL;
> > + goto out;
> > + }
> > +
> > ret = plane->funcs->update_plane(plane, crtc, fb,
> > plane_req->crtc_x, plane_req->crtc_y,
> > plane_req->crtc_w, plane_req->crtc_h,
>
> Good sanity check (saves the drivers from having to do it), but I
> wonder if we can use a better return value like ENOSPC or something to
> make it easier for userspace to figure out.
Yeah, getting EINVAL for every kind of failure is rather annoying. The
only issue I have with ENOSPC is the strerror() output. It doesn't
exactly fit this use case. But if there's nothing better I'm OK with
ENOSPC.
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
