Message-ID: <93d3802305fa348738dae7f458c3fb56.squirrel@www.codeaurora.org>
Date:	Tue, 7 Apr 2015 15:55:45 -0000
From:	jilaiw@...eaurora.org
To:	"Rob Clark" <robdclark@...il.com>,
	"Jilai Wang" <jilaiw@...eaurora.org>,
	"linux-arm-msm" <linux-arm-msm@...r.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH 2/3] drm:msm: Initial Add Writeback Support

> 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.

During streaming, drm application just does normal page_flip while v4l
application queues/dequeues v4l buffers.

Thanks,
Jilai


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists