From 6228d186f2012ab1a574ea291ece16f49d32e3cf Mon Sep 17 00:00:00 2001 From: Nicolas Dufresne Date: Sun, 7 Dec 2014 17:33:51 -0500 Subject: v4l2: Workaround libv4l2 RW emulation bug When libv4l2 emulates RW mode on top of MMAP devices, the queues are only initialized on first read. The problem is that poll() will fail if called before the queues are initialized and streaming. Workaround this by doing a zero size read when pool is started in that IO mode. https://bugzilla.gnome.org/show_bug.cgi?id=740633 --- sys/v4l2/gstv4l2bufferpool.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/sys/v4l2/gstv4l2bufferpool.c b/sys/v4l2/gstv4l2bufferpool.c index 6a12874d9..81f7d5b8d 100644 --- a/sys/v4l2/gstv4l2bufferpool.c +++ b/sys/v4l2/gstv4l2bufferpool.c @@ -644,6 +644,15 @@ gst_v4l2_buffer_pool_start (GstBufferPool * bpool) switch (obj->mode) { case GST_V4L2_IO_RW: can_allocate = TRUE; +#ifdef HAVE_LIBV4L2 + /* This workaround a unfixable bug in libv4l2 when RW is emulated on top + * of MMAP. In this case, the first read initialize the queues, but the + * poll before that will always fail. Doing an empty read, forces the + * queue to be initialized now. We only do this if we have a streaming + * driver. */ + if (obj->vcap.capabilities & V4L2_CAP_STREAMING) + v4l2_read (obj->video_fd, NULL, 0); +#endif break; case GST_V4L2_IO_DMABUF: case GST_V4L2_IO_MMAP: -- cgit v1.2.3