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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
