IMX Scaler / CSC m2m driver.

Jean-Michel Hautbois jhautbois at gmail.com
Wed Mar 25 07:29:43 PDT 2015


2015-03-25 12:36 GMT+01:00 Nicolas Dufresne <nicolas.dufresne at collabora.com>:
> Le mercredi 25 mars 2015 à 11:02 +0000, Ian Molton a écrit :
>> I may be misunderstanding something here, but presumably, all the
>> buffers used by hardware are allocated in the kernel, wether they be
>> GFP_DMA or GFP_KERNEL. I dont see why userspace would want to
>> read / write a buffer between v4l2video3videodec and
>> v4l2video0convert,
>> so surely all userspace needs to do is tell the kernel which buffer to
>> pass along? after all, its allocated in kernel, written in kernel, and
>> will be consumed by another driver from kernel memory. Why is
>> userspace
>> even trying to copy the data at all?
>
> The thread name does not mean this element is doing the copy. The thread
> name simply say which element is running a streaming thread.
>
> The remaining copy happens in ximagesink, because we need to copy to
> shared X11 server memory. Unless your converter driver can do
> capture-io-mode=userptr, there is nothing GStreamer can do about this
> copy. It's X11 design that you get X11 to allocate the memory (even
> though it's often normal vmalloc memory, and that the server often need
> to copy again).

I get this observation as an input (I can open a new thread though) :
right now, we do not have a zero-copy driver for a HDMI output.
So, we need to either use fbdevsink (and convert, copy, etc.) or
ximagesink, with the remarks Nicolas just gave.

Philipp, maybe do you have a v4l2sink compatible driver in your pocket :) ?
If not, what is needed exactly to have one ?

Thanks,
JM


More information about the gstreamer-devel mailing list