Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753342AbbDHIFT (ORCPT ); Wed, 8 Apr 2015 04:05:19 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:36117 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751287AbbDHIFM (ORCPT ); Wed, 8 Apr 2015 04:05:12 -0400 Date: Wed, 8 Apr 2015 10:07:07 +0200 From: Daniel Vetter To: jilaiw@codeaurora.org Cc: Rob Clark , linux-arm-msm , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" Subject: Re: [PATCH 2/3] drm:msm: Initial Add Writeback Support Message-ID: <20150408080707.GN6354@phenom.ffwll.local> Mail-Followup-To: jilaiw@codeaurora.org, Rob Clark , linux-arm-msm , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" References: <1427922770-13721-1-git-send-email-jilaiw@codeaurora.org> <20150407055949.GI6354@phenom.ffwll.local> <93d3802305fa348738dae7f458c3fb56.squirrel@www.codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93d3802305fa348738dae7f458c3fb56.squirrel@www.codeaurora.org> X-Operating-System: Linux phenom 4.0.0-rc3+ User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4181 Lines: 84 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/