Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit :
> On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote:
> > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at
> > > runtime ?
> >
> > Does CREATE_BUFS always work while already stre
Le jeudi 2 ao?t 2012 09:35:58 Hans Verkuil, vous avez ?crit :
> On Wed August 1 2012 22:49:57 R?mi Denis-Courmont wrote:
> > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at
> > > runtime ?
> >
> > Does CREATE_BUFS always work while already streaming has already started?
> > If
Le mercredi 1 ao?t 2012 14:35:03 Laurent Pinchart, vous avez ?crit :
> > But in general, the V4L element in the pipeline does not know how fast
> > the downstream element(s) will consume the buffers. Thus it has to copy
> > from the MMAP buffers into anonymous user memory pending processing.
> > Th
Does CREATE_BUFS always work while already streaming has already started? If
it depends on the driver, it's kinda helpless.
What's the guaranteed minimum buffer count? It seems in any case, MMAP has a
hard limit of 32 buffers (at least videobuf2 has), though one might argue this
On Tue, 31 Jul 2012 23:52:35 +0200, Laurent Pinchart
wrote:
>> I want to receive the video buffers in user space for processing.
>> Typically
>> "processing" is software encoding or conversion. That's what virtually
>> any
>> V4L application does on the desktop...
>
> But what prevents you from u
for the exact same
DMABUF patch series...
--
Rémi Denis-Courmont
Sent from my collocated server
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Le mardi 31 juillet 2012 19:28:12 Laurent Pinchart, vous avez écrit :
> Hi Rémi,
>
> On Tuesday 31 July 2012 16:39:00 Rémi Denis-Courmont wrote:
> > Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit :
> > > > For that matter, wouldn't it be usefu
Le mardi 31 juillet 2012 17:03:52 Rob Clark, vous avez écrit :
> On Tue, Jul 31, 2012 at 8:39 AM, Rémi Denis-Courmont
wrote:
> > Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit :
> >> > For that matter, wouldn't it be useful to support exporting
MMAP requires memory copying.
I am not sure DMABUF even supports transmitting data efficiently to userspace.
In my understanding, it's meant for transmitting data between DSP's bypassing
userspace entirely, in other words the exact opposite of what USERBUF does.
--
Rémi Deni
Le mardi 31 juillet 2012 19:28:12 Laurent Pinchart, vous avez ?crit :
> Hi R?mi,
>
> On Tuesday 31 July 2012 16:39:00 R?mi Denis-Courmont wrote:
> > Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez ?crit :
> > > > For that matter, wouldn't it be useful to support exporting a userptr
>
Le mardi 31 juillet 2012 17:03:52 Rob Clark, vous avez ?crit :
> On Tue, Jul 31, 2012 at 8:39 AM, R?mi Denis-Courmont
wrote:
> > Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez ?crit :
> >> > For that matter, wouldn't it be useful to support exporting a userptr
> >> > buffer at some
Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez ?crit :
> > For that matter, wouldn't it be useful to support exporting a userptr
> > buffer at some point in the future?
>
> Shouldn't USERPTR usage be discouraged once we get dma-buf support ?
USERPTR, where available, is currently t
On Fri, 20 Apr 2012 14:25:01 +0200, Tomasz Stanislawski
wrote:
>>> The USERPTR simplifies userspace code but introduce
>>> a lot of complexity problems for the kernel drivers
>>> and frameworks.
>>
>> It is not only a simplification. In some cases, USERPTR is the only I/O
>> method that supports
On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski
wrote:
>> Am I understanding wrong or are you saying that you want to drop
userptr
>> from V4L2 API in long-term? If so, why?
>
> Dropping userptr is just some brainstorming idea.
> It was found out that userptr is not a good mean
> for buff
can support USERPTR.
> The userptr has its niches were it works pretty well like Web cams or
VIVI.
> I am saying that if ever DMABUF becomes a good alternative for USERPTR
> than maybe we should consider encouraging dropping USERPTR in the new
> drivers as 'obsolete' feature a
not.
Now, I do realize that some devices cannot support USERPTR efficiently,
then they should not support USERPTR. But for those devices that can, it
seems quite a nice performance enhancement.
--
Rémi Denis-Courmont
Sent from my collocated server
___
num_users, vaddr
> + * Required ops for DMABUF types: attach_dmabuf, detach_dmabuf,
> map_dmabuf, + * unmap_dmabuf.
> */
> struct vb2_mem_ops {
> void*(*alloc)(void *alloc_ctx, unsigned long size);
> @@ -65,6 +82,17 @@ struct vb2
UF
> +returns immediately with an &EAGAIN; when no buffer is available. The
> +&func-select; or &func-poll; function are always available.
> +
> +To start and stop capturing or output applications call the
> +&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note
&g
Le jeudi 5 avril 2012 17:00:00 Tomasz Stanislawski, vous avez ?crit :
> From: Sumit Semwal
>
> This patch adds support for DMABUF memory type in videobuf2. It calls
> relevant APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
>
> For this version, the support is for videobuf2 as a user o
Le jeudi 5 avril 2012 16:59:59 Tomasz Stanislawski, vous avez ?crit :
> This patch adds description and usage examples for importing
> DMABUF file descriptor in V4L2.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> ---
> Documentation/DocBook/media/v4l/compat.xml
20 matches
Mail list logo
