About switching between V4L2_BUF_TYPE_VIDEO_CAPTURE and V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE capture buffers in v4l2-mem2mem, across instances

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I'm using the v4l2-mem2mem infrastructure for a driver I'm writing and
I'm looking if it's possible to have the capture vb2_queue to take
both V4L2_BUF_TYPE_VIDEO_CAPTURE and
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE buffers, across instances.

The IP I'm writing the driver for, handles
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE natively (NV1xM buffers), but I'd
also need to support V4L2_BUF_TYPE_VIDEO_CAPTURE as this type is also
standard and more application friendly (NV12 and NV16 buffers).

In v4l2-mem2mem, v4l2_m2m_ctx_init(), usually called in the device
driver's v4l2_file_operations::open() handler, is used to setup
(statically) both the output and capture queues of a v4l2-mem2mem
device.

Setting up the queues types (output and capture) in open() isn't
practical for my case, as we can't signal yet the desired type of the
capture buffer at that stage. The only way I could find is to call
v4l2_m2m_ctx_init() during v4l2_ioctl_ops::vidioc_reqbufs() instead;
where depending on the v4l2_requestbuffers::type, I could initialize a
mem2mem context with a V4L2_BUF_TYPE_VIDEO_CAPTURE or a
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE capture buffer.

The problem is that for the context to be correctly created, userspace
has to issue a reqbufs() for the capture buffers first, and then for
the output buffers. Doing it for the output buffers first, would yield
a call to v4l2_m2m_ctx_init() with an incomplete information about the
capture buffers type. Once buffers are requested for a certain type,
they remain of that type until the instance is closed, or
vidioc_reqbufs() is called w/ v4l2_requestbuffers::count == 0.

I could get vidioc_reqbufs() to enforce this logic and only succeed if
capture buffers are requested before output buffers; but still this
limitation sounds like an artificial and unnecessary.

Do you guys think that this is worth fixing in v4l2-mem2mem? If not,
is there another proper way to handle both V4L2_BUF_TYPE_VIDEO_CAPTURE
and V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE capture buffers in capable
v4l2-mem2mem devices?

Regards,

-Ilyes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux