Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane

[Thomas Hellstrom <thomas@shipmail.org>]

Hi,

On 01/04/2018 02:52 PM, Lukasz Spintzyk wrote:
>
>
>
> On 28/12/2017 10:03, Thomas Hellstrom wrote:
>> Hi, Lukasz!
>>
>> (Sorry for top-posting).
>>
>> We have Deepak from our team working on the same subject. I think 
>> he's in over the holidays so I'll add him to the CC list.
> Great!
>>
>> Adding damage to the plane state is, IMO the correct way to do it. 
>> However, from your proposal it's not clear whether damage is given in 
>> the plane-, crtc- or framebuffer coordinates. The last conclusion 
>> from our email thread discussion was that they should be given in 
>> framebuffer coordinates with helpers to compute plane coordinates or 
>> crtc coordinates. The reason being that it's easier for user-space 
>> apps to send damage that way, and again, we have the full information 
>> that we can clip and scale if necessary. Most drivers probably want 
>> the damage in clipped plane- or crtc coordinates. Helpers could for 
>> example be in the form of region iterators.
> Personally i don't know the difference between plane rects and 
> framebuffer rects. I don't know what would be better. I was thinking 
> about coordinates of framebuffer that is attached to drm_plane_state.

A given point with coordinates (0, 0) in the plane coordinate system 
would have (state->crtc_x, state->crtc_y) in the crtc coordinate system 
and (state->src_x, state->src_y) in the framebuffer coordinate system.

So the question is, which is the suitable coordinate system, and where 
is the origin for the damage rects?

>>
>> Full (multi-rect) damage regions are OK with us, although we should 
>> keep in mind that we won't be able to compute region unions in the 
>> kernel (yet?). Implying: Should we forbid overlapping rects at the 
>> interface level or should we just recommend rects not to be 
>> overlapping? The former would be pretty hard to enforce efficiently.
> I would be for recommendation. We can add some helper functions to 
> combine rects and set some limits on number of rects to prevent abuse 
> of that interface.

I agree.

>>
>> Another thing we should think about is how to use this interface for 
>> the legacy "dirtyfb" call. Probably we need to clear the damage 
>> property on each state-update, or set a flag that "this is a dirtyfb 
>> state update".
>>
>> IMO we should also have as an end goal of this work to have 
>> gnome-shell on drm sending damage regions on page-flip, which means 
>> either porting gnome-shell to atomic or set up a new legacy 
>> page-flip-with-atomic ioctl.
> Can't we reuse dirtyfb ioctl for this purpose? It would be called 
> before page_flip ioctl?

No we can't. The dirtyfb ioctl causes an immediate repaint of the 
damaged region.

/Thomas

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