On Tue, Aug 12, 2014 at 10:03:26AM +0200, Daniel Vetter wrote:
On Tue, Aug 12, 2014 at 9:20 AM, Pekka Paalanen ppaalanen@gmail.com wrote:
but I tend to think it would be nice for compositors (userspace) to know explicitly what is going on.. ie. if some layers are blended via intermediate buffer, couldn't that intermediate buffer be potentially re-used on next frame if not damaged?
Very true, and I think that speaks for exposing the HVS explicitly to user space to be directly used. That way I believe the user space could track damage and composite only the minimum, rather than everything every time which I suppose the KMS API approach would imply.
We don't have dirty regions in KMS API/props, do we? But yeah, that is starting to feel like a stretch to push through KMS.
We have the dirty-ioctl, but imo it's a bit misdesigned: It works at the framebuffer level (so the driver always has to figure out which crtc/plane this is about), and it only works for frontbuffer rendering. It was essentially a single-purpose thing for udl uploads.
But in generally I think it would make tons of sense to supply a per-crtc (or maybe per-plane) damage rect with nuclear flips. Both mipi dsi and edp have provisions to upload a subrect, so this could be useful in general. And decent compositors compute this already anyway.
Agreed, as long as we make it more of a hint so that the driver is allowed to expand the rect to satisfy hardware specific alignment requirements and whatnot.
I think a single per-crtc rect should be enough, but in case people would like to implement a more sophisticated multi-rect update I suppose we could allow it. And for those that don't want the extra complexity of trying to deal with multiple rectangles, the driver could just calculate the bounding rectangle and update that.