VIDIOC_REQBUFS and video_stream

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

gstreamer's v4l2src fails with

  Buffer pool activation failed

This can be traced to VIDIOC_REQBUFS (2 mmap buffers) returning EBUSY
in video_stream_setup_bufs:
https://nxr.netbsd.org/xref/src/sys/dev/video.c#2315

  2310      /* Ensure that all allocated buffers are queued and not under
  2311       * userspace control. */
  2312      for (i = 0; i < vs->vs_nbufs; ++i) {
  2313          if (!(vs->vs_buf[i]->vb_buf->flags & V4L2_BUF_FLAG_QUEUED)) {
  2314              mutex_exit(&vs->vs_lock);
  2315              return EBUSY;
  2316          }
  2317      }

Further up in video.c is an explanation is what is meant to happen:

   151      /* Video samples may exist in different locations.  Initially,
   152       * samples are queued into the ingress queue.  The driver
   153       * grabs these in turn and fills them with video data.  Once
   154       * filled, they are moved to the egress queue.  Samples are
   155       * dequeued either by user with MMAP method or, with READ
   156       * method, videoread() works from the fist sample in the
   157       * ingress queue without dequeing.  In the first case, the
   158       * user re-queues the buffer when finished, and videoread()
   159       * does the same when all data has been read.  The sample now
   160       * returns to the ingress queue. */

The VIDIOC_REQBUFS man page says:

  Memory mapped buffers are located in device memory and must be
  allocated with this ioctl before they can be mapped into the
  application's address space.

AFAICT the first thing gstreamer must do is call VIDIOC_REQBUFS?
Afterwards read on /dev/video? might call video_stream_enqueue to
set V4L2_BUF_FLAG_QUEUED. But then VIDIOC_REQBUFS will always fail?

("Initially, samples are queued into the ingress queue." by what?)

Thoughts?

Cheers,

Patrick