How to design a DRM KMS driver exposing 2D compositing?

[Daniel Vetter]

On Tue, Aug 12, 2014 at 9:20 AM, Pekka Paalanen <ppaalanen at 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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch