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