Re: [PATCH 2/3] drm:msm: Initial Add Writeback Support

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Apr 07, 2015 at 03:55:45PM -0000, jilaiw@codeaurora.org wrote:
> > On Thu, Apr 02, 2015 at 10:29:52AM -0400, Rob Clark wrote:
> >> So, from a quick look, it seems like there is a lot of potential to
> >> split the v4l part out into some drm helpers.. it looks pretty
> >> generic(ish), or at least it could be with some strategically placed
> >> vfuncs in drm_v4l2_helper_funcs.
> >>
> >> I do think we need to figure out the auth/security situation.  We
> >> probably don't want to let arbitrary processes open a v4l device and
> >> snoop on the screen contents.  We perhaps could re-use the dri2 drm
> >> auth stuff (v4l2_drm_get_magic ioctl?).  Or, well, it would be nice if
> >> the wb device could be made to not exist in /dev at all, and
> >> pre-open'd fd returned from an ioctl on the drm device, but not really
> >> sure if that is possible (or too weird).  Once the compositor process
> >> has the v4l device open and authenticated somehow, I expect it would
> >> use fd passing to pass the fd off to a trusted helper process.
> >
> > Please don't resurrect the magic stuff ;-)
> >
> > Anyway I discussed this a bit with Laurent and we figured the best way to
> > wire up writeback support is by using drm framebuffers. Then you can use
> > atomic flips to create a new snapshot. Of course that won't work with hw
> > where writeback is continuous, there v4l is a much better fit. And we also
> > have hardware where some v4l pipeline could directly feed into a drm
> > output pipeline, so we need a generic way to connect v4l and drm anyway.
> > For that I think we should add a new flag to addfb2 (or a new addfbv4l)
> > which creates a magic framebuffer from a v4l input/output. Some values
> > like stride don't make sense in such a virtual framebuffer, but pixel
> > format and size are all needed.
> >
> > This way we don't need parallel abis for single-shot writeback directly
> > into framebuffers and for continuous writeback through v4l, we can reuse
> > the same drm framebuffer ones. And this also solves the security issues
> > since no one can start writeback without the drm device owner's consent,
> > so no need to reinvent anything there. And with atomic we already have
> > almost everything there: For the writeback framebuffer we only need a new
> > "WRITEBACK" property (which takes an fb id) and the small extension to
> > create v4l-backed framebuffers.
> >
> > Cheers, Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
> Hi Daniel,
> 
> 1. This change is to implement a continuous writeback.
> 2. As you said, we need "a generic way to connect v4l and drm".
> Especially how to share the buffer information between v4l and drm for
> writeback output.
> 
> Below are just some details of this change:
> 
> In current implementation, I expect the output buffer is dma buffer
> which could be from GEM object (drm) or from video encoder (V4l). Once
> the buffer is queued into V4l driver, it will be converted into a GEM
> object and then pass it to drm as writeback output buffer. Once the
> buffer is captured, it will notify V4l driver to let user dequeue
> buffer.
> 
> Drm will notice there is a Virtual Connector (maybe a new type WRITEBACK
> can be added), but it will only be "connected" until V4l
> starts streaming.

Yes we definitely should add a new connector type WRITEBACK. And just the
connector kinda works for your hw design where writeback works like a
separate encoder. But there's also hw out there where any crtc can be
written back, and for those cases we need explicit properties. Then
there's also the one-shot vs. continuous issues.

Given all that I still think you want an explicit drm framebuffer to
connect the kms and the v4l side of things. That would also help a bit
with making it clear which v4l connects to which drm device.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch