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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
