[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SN6PR05MB39509833C3635F1F52CFABE6BABF0@SN6PR05MB3950.namprd05.prod.outlook.com>
Date: Mon, 9 Apr 2018 16:44:38 +0000
From: Deepak Singh Rawat <drawat@...are.com>
To: Daniel Vetter <daniel@...ll.ch>
CC: "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
Thomas Hellstrom <thellstrom@...are.com>,
Sinclair Yeh <syeh@...are.com>,
linux-graphics-maintainer <linux-graphics-maintainer@...are.com>,
"ville.syrjala@...ux.intel.com" <ville.syrjala@...ux.intel.com>,
"lukasz.spintzyk@...playlink.com" <lukasz.spintzyk@...playlink.com>,
"noralf@...nnes.org" <noralf@...nnes.org>,
"robdclark@...il.com" <robdclark@...il.com>,
"gustavo@...ovan.org" <gustavo@...ovan.org>,
"maarten.lankhorst@...ux.intel.com"
<maarten.lankhorst@...ux.intel.com>,
"seanpaul@...omium.org" <seanpaul@...omium.org>,
"airlied@...ux.ie" <airlied@...ux.ie>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane
> > > > +void drm_plane_enable_damage_clips(struct drm_plane *plane)
> > > > +{
> > > > + struct drm_device *dev = plane->dev;
> > > > + struct drm_mode_config *config = &dev->mode_config;
> > > > +
> > > > + drm_object_attach_property(&plane->base, config-
> > > >prop_damage_clips, 0);
> > > > +}
> > > > diff --git a/include/drm/drm_mode_config.h
> > > b/include/drm/drm_mode_config.h
> > > > index 7569f22..d8767da 100644
> > > > --- a/include/drm/drm_mode_config.h
> > > > +++ b/include/drm/drm_mode_config.h
> > > > @@ -628,6 +628,21 @@ struct drm_mode_config {
> > > > */
> > > > struct drm_property *prop_crtc_id;
> > > > /**
> > > > + * @prop_damage_clips: Optional plane property to mark damaged
> > > regions
> > > > + * on the plane in framebuffer coordinates of the framebuffer
> > > attached
> > > > + * to the plane.
> > >
> > > Why should we make this optional? Looks like just another thing drivers
> > > might screw up, since we have multiple callbacks and things to set up for
> > > proper dirty tracking.
> >
> > Thanks Daniel for the review.
> >
> > I think not all compositor will be interested in sending damage, that was the
> > reason to make this optional. Also when damage is not set that means
> > user-space need full update just like eglSwapBuffersWithDamageKHR.
> >
> > I will add better documentation.
>
> I think if we also handle this case in the helper that'd be even better:
> In the case of no damage, the helper/core code could automatically supply
> a damage rect for the entire buffer. That way drivers don't have to handle
> this case specially.
> -Daniel
Agreed.
> --
Powered by blists - more mailing lists