On 11/15/2018 08:49 AM, Laurent Pinchart wrote:
> Hi Hans,
>
>
> On Thursday, 15 November 2018 09:30:55 EET Hans Verkuil wrote:
>> On 11/14/2018 08:52 PM, Laurent Pinchart wrote:
>>> On Tuesday, 13 November 2018 17:43:48 EET Hans Verkuil wrote:
On 11/13/18 16:06, Philipp Zabel wrote:
>
Hi Hans,
On Thursday, 15 November 2018 09:30:55 EET Hans Verkuil wrote:
> On 11/14/2018 08:52 PM, Laurent Pinchart wrote:
> > On Tuesday, 13 November 2018 17:43:48 EET Hans Verkuil wrote:
> >> On 11/13/18 16:06, Philipp Zabel wrote:
> >>> From: John Sheu
> >>>
> >>> Videobuf2 presently does
On 11/14/2018 08:52 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Tuesday, 13 November 2018 17:43:48 EET Hans Verkuil wrote:
>> On 11/13/18 16:06, Philipp Zabel wrote:
>>> From: John Sheu
>>>
>>> Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
>>> buffers if the queue is
Hi Hans,
On Tuesday, 13 November 2018 17:43:48 EET Hans Verkuil wrote:
> On 11/13/18 16:06, Philipp Zabel wrote:
> > From: John Sheu
> >
> > Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
> > buffers if the queue is of type V4L2_MEMORY_MMAP, and if the buffers are
> >
On 11/14/18 15:43, Philipp Zabel wrote:
> Hi Hans,
>
> On Tue, 2018-11-13 at 16:43 +0100, Hans Verkuil wrote:
>> Hi Philipp,
>>
>> On 11/13/18 16:06, Philipp Zabel wrote:
>>> From: John Sheu
>>>
>>> Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
>>> buffers if the queue
Hi Hans,
On Tue, 2018-11-13 at 16:43 +0100, Hans Verkuil wrote:
> Hi Philipp,
>
> On 11/13/18 16:06, Philipp Zabel wrote:
> > From: John Sheu
> >
> > Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
> > buffers if the queue is of type V4L2_MEMORY_MMAP, and if the
Hi Sakari,
On Wed, 2018-11-14 at 00:27 +0200, Sakari Ailus wrote:
[...]
> This lets the user to allocate lots of mmap'ed buffers that are pinned in
> physical memory.
This is already possible without this patch, by closing the fd instead
of calling reqbufs(0).
> Considering that we don't really
On Wed, Nov 14, 2018 at 8:51 AM Nicolas Dufresne wrote:
>
> Le mercredi 14 novembre 2018 à 00:27 +0200, Sakari Ailus a écrit :
> > Hi Philipp,
> >
> > On Tue, Nov 13, 2018 at 04:06:21PM +0100, Philipp Zabel wrote:
> > > From: John Sheu
> > >
> > > Videobuf2 presently does not allow
Le mercredi 14 novembre 2018 à 00:27 +0200, Sakari Ailus a écrit :
> Hi Philipp,
>
> On Tue, Nov 13, 2018 at 04:06:21PM +0100, Philipp Zabel wrote:
> > From: John Sheu
> >
> > Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
> > buffers if the queue is of type
Hi Philipp,
On Tue, Nov 13, 2018 at 04:06:21PM +0100, Philipp Zabel wrote:
> From: John Sheu
>
> Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
> buffers if the queue is of type V4L2_MEMORY_MMAP, and if the buffers are
> considered "in use". This is different behavior
Hi Philipp,
On 11/13/18 16:06, Philipp Zabel wrote:
> From: John Sheu
>
> Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
> buffers if the queue is of type V4L2_MEMORY_MMAP, and if the buffers are
> considered "in use". This is different behavior than for other memory
Sorry, that should have said [PATCH v2].
regards
Philipp
From: John Sheu
Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
buffers if the queue is of type V4L2_MEMORY_MMAP, and if the buffers are
considered "in use". This is different behavior than for other memory
types and prevents us from deallocating buffers in following
Hi Tomasz,
I think this makes sense. After all, just closing the filehandle has the
same effect. However, I would like to see some documentation improvements
to go along with this vb2 patch.
1) The VIDIOC_REQBUFS ioctl documentation needs to be extended so it
describes that it is OK to do this
From: John Sheu
Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
buffers if the queue is of type V4L2_MEMORY_MMAP, and if the buffers are
considered "in use". This is different behavior than for other memory
types and prevents us from deallocating
15 matches
Mail list logo