Re: [RFC 0/3] drm: page-flip with damage

[Lukasz Spintzyk <lukasz.spintzyk@displaylink.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3182 bytes --]

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


On 05/04/2018 01:49, Deepak Rawat wrote:
> 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
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel 
> <https://lists.freedesktop.org/mailman/listinfo/dri-devel>


[-- Attachment #1.2: Type: text/html, Size: 4449 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel