I think we can add application-supplied streaming buffers to the API without 'disturbing' the existing interface semantics. How about this: 1) QUERYCAP QUERYCAP will set the flag V4L2_FLAG_USERBUFFERS in v4l2_capability.flags if the driver supports user-supplied streaming buffers. 2) REQBUFS To tell the driver the application wants to supply the streaming buffers to the driver, the app adds the V4L2_BUF_REQ_USER flag to v4l2_requestbuffers.type in the REQBUFS call. 3) QUERYBUF QUERYBUF works as before from the application POV. The driver knows there is no mmap() coming. The app does no mmap(). 4) QBUF Add a field "char *userptr;" to v4l2_buffer. The application will pass its buffer to the driver in the QBUF call by setting the userptr field. The application must ensure that the buffer is at least v4l2_buffer.length bytes long. The driver locks the memory on QBUF if it needs to. 5) DQBUF DQBUF works as before from the application POV. The driver unlocks the memory, if it was locked, before the DQBUF returns. That's it. It's backward compatible all around. It makes sense to me to pass the buffer on QBUF, not QUERYBUF, and no new REQBUFS=0 semantics is required. I understand the desire to save locking and unlocking the memory each time it is used, but don't think it's a significant overhead considering the memcpy() that is being avoided. Having separate pointers and strides for multi-plane formats is a separate and orthogonal issue from whether buffers are app-allocated or driver-allocated. I have a couple questions. Is there some friendly documentation on memory locking and DMA to userspace in 2.4 somewhere (besides the source code)? What if a malicious or buggy program free()s the buffers while the driver still has them? Can it crash the system? Can the driver know if that happens like it can catch a munmap()? Bill.
