Hi,
On 06/07/2012 08:43 AM, Hans Verkuil wrote:
On Thu June 7 2012 02:52:06 Laurent Pinchart wrote:
On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote:
On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
I have a system where
On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
Hi Rebecca,
On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for the planes. I can't
figure out how to do that with
Hi Hans,
On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote:
On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for
On Mon June 4 2012 23:58:07 Hans Verkuil wrote:
Hi Rebecca,
On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote:
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for the planes. I can't
figure out how to do that with the
Hi Rebecca,
On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for the planes. I can't
figure out how to do that with the current dma_buf implementation. I
thought I could
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for the planes. I can't
figure out how to do that with the current dma_buf implementation. I
thought I could pass the same dma_buf several times and use the
data_offset field of the
this is at least how we do it w/ drm/kms.. I would expect that if you
could do that w/ output for v4l you also could for input, but perhaps
the individual driver needs to do something to support mplane? I
guess the v4l folks would know better
BR,
-R
On Tue, Jun 5, 2012 at 3:34 AM, Rebecca
I'm trying to do it in my drivier, but I'm not sure how to make it
safe since there is no way to tell the kernel the total size of the
buffer. From what I can tell, I can't sanity check that the offset
and lengths are within the buffer without adding a field.
Rebecca
On Mon, Jun 4, 2012 at 1:28
Also the data_offset field (and bytes_used field) only get copied
from the v4l2_buffer into the vb2_buffer struct if the buffer is an
output buffer.
Rebecca
On Mon, Jun 4, 2012 at 1:46 PM, Rebecca Schultz Zavin
rebe...@android.com wrote:
I'm trying to do it in my drivier, but I'm not sure how
can you check expected size vs dmabuf-size - offset?
On Tue, Jun 5, 2012 at 4:46 AM, Rebecca Schultz Zavin
rebe...@android.com wrote:
I'm trying to do it in my drivier, but I'm not sure how to make it
safe since there is no way to tell the kernel the total size of the
buffer. From what I can
Hi Rebecca,
On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote:
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for the planes. I can't
figure out how to do that with the current dma_buf implementation. I
thought I could pass
It probably is a fixed offset, but all the information describing it
is in userspace... In my experience, it's always almost one of the
pre-defined formats, but then there's some extra padding, weird
alignment etc. I'm trying to convert code that used userptr, but
where the planes were offsets
On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Tomasz,
Hi Tomasz, Laurent, Mauro,
On Wednesday 23 May 2012 14:10:14 Tomasz Stanislawski wrote:
Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for
Hi Tomasz,
On Wednesday 23 May 2012 14:10:14 Tomasz Stanislawski wrote:
Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski
Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski [4].
v6:
- fixed missing entry in v4l2_memory_names
- fixed a bug occuring
15 matches
Mail list logo
