<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi, Many thanks that you have picked it up. Unfortunately I didn't had time to work on it for a while. I am ok with what you have done, ihmo the review is going in good direction. I will try not to miss your update of it. From my side I can say that damage rects with frame-buffer coordinates are perfectly fine for DisplayLink case. Btw I have noticed that there is also a patch from Rob Clark that is supplying helper for legacy dirtyfb callback. Maybe we should unify the naming of the rects. Here we have "damage_clips", Clark's patch has 'dirty_rects' notion. On other hand existing legacy dirtyfb callback in drm_framebuffer_funcs is also using 'clip_rects' :). Thanks Łukasz Spintzyk <div class="moz-cite-prefix">On 05/04/2018 01:49, Deepak Rawat wrote: </div> <blockquote type="cite" cite="mid:1522885748-67122-1-git-send-email-drawat@vmware.com"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> Hi All, This is extension to Lukasz Spintzyk earlier draft of damage interface for drm. Bascially a new plane property is added called "DAMAGE_CLIPS" which is simply an array of drm_rect (exported to userspace as drm_mode_rect). The clips represents damage in framebuffer coordinate of attached fb to the plane. Helper iterator is added to traverse the damage rectangles and get the damage clips in framebuffer, plane or crtc coordinates as need by driver implementation. Finally a helper to reset damage in case need full update is required. Drivers interested in page-flip with damage should call this from atomic_check hook. With the RFC for atomic implementation of dirtyfb ioctl I was thinking should we need to consider dirty_fb flags, especially DRM_MODE_FB_DIRTY_ANNOTATE_COPY to be passed with atomic DAMAGE_CLIPS property blob? I didn't considered that untill now. If no driver uses that in my opinion for simplicity this can be ignored? About overlaping of damage rectangles is also not finalized. This really depends on driver specific implementation and can be left open-ended? My knowledge is limited to vmwgfx so would like to hear about other driver use cases and this can be modified in keeping other drivers need. Going forward driver implementation for vmwgfx and user-space implementation of kmscube/weston will be next step to test the changes. Thanks, Deepak Deepak Rawat (2): drm: Add helper iterator functions to iterate over plane damage. drm: Add helper to validate damage during modeset_check Lukasz Spintzyk (1): drm: Add DAMAGE_CLIPS property to plane drivers/gpu/drm/drm_atomic.c | 42 +++++++++ drivers/gpu/drm/drm_atomic_helper.c | 173 ++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_mode_config.c | 5 ++ drivers/gpu/drm/drm_plane.c | 12 +++ include/drm/drm_atomic_helper.h | 41 +++++++++ include/drm/drm_mode_config.h | 15 ++++ include/drm/drm_plane.h | 16 ++++ include/uapi/drm/drm_mode.h | 15 ++++ 8 files changed, 319 insertions(+) -- 2.7.4 _______________________________________________ dri-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a> <a moz-do-not-send="true" href="https://lists.freedesktop.org/mailman/listinfo/dri-devel">https://lists.freedesktop.org/mailman/listinfo/dri-devel</a> </blockquote> </body> </html>