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

Pekka Paalanen ppaalanen at gmail.com
Fri Sep 7 09:27:04 UTC 2018


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,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180907/ce80bab4/attachment.sig>


More information about the dri-devel mailing list