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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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.

-- 
Ville Syrjälä
Intel OTC