[PATCH 01/14] drm: add new plane property FB_DAMAGE_CLIPS to send damage during plane update

[Deepak Singh Rawat]

> 
> On Thu, 6 Sep 2018 21:36:51 +0000
> Deepak Singh Rawat <drawat at vmware.com> wrote:
> 
> > >
> > > - Why no input validation on the damage clips against the framebuffer
> > >   size? Ime not validating just leads to funny driver bugs down the road,
> > >   so what's the use-case you have in mind here?
> >
> > My motivation behind not informing user-space if damage is outside plane
> > src, sent during modeset(where it should be provided) or damage is outside
> > framebuffer coordinate (simply put damage clips are invalid) is that it's a
> > hint. The contract between kernel and user-space is simple, if damage
> > clips are valid, kernel might use them (but not always) otherwise they
> > will be ignored. Damage can be ignored deep in the stack (like network),
> > so all the input validation for nothing.
> >
> > Also, what all to consider in input validation ?
> > * clips are outside plane src
> > * damage clips sent during modeset should error ?
> > * any other properties.
> >
> > This will lead to a complex input validation during modeset check like
> > if some drivers are OK with damage while scaling whereas others
> > cannot support, should this error?
> >
> > However I am alright doing input validation if this becomes clear what
> > kind of validation to actually do. My understanding of drm core is limited.
> 
> Hi,
> 
> I think validating that the area of any clip rectangle does not extend
> beyond the framebuffer size would be good. A userspace violating that
> is arguably broken, so it would help catch userspace bugs.
> 
> I also would not assume that damage is irrelevant on modeset. Userspace
> does not always know if an update will be a modeset or not: drivers vary
> there, and userspace that just wants the update through will allow
> modesets always while still providing damage. Userspace could also
> change video mode timings or pixel format while keeping the resolution
> the same, and in that case damage could be meaningful to a driver.
> 
Thanks Pekka, for explanation. I agree clips outside framebuffer should
be errored and also it's not a lot for drm core. Also, will look into the
cases where drm core should clear the damage clips, like resolution
change, etc.

May be the better approach would be drm core just provide the helper
and driver takes care of driver specific scenarios.