> > Hmm, V4L2_FLAG_DMA is a bad name. Capture to mmap()'ed kernel buffers is > > DMA too... > > V4L2_FLAG_USERDMA ? Better. Maybe USERBUFFER? Not all devices do busmaster dma (usb webcams...). > > Hmm, you mix up buffers + format here. "stride" is redundant with > > v4l2_pix_format.bytesperline, which is a bad idea IMHO. > > > > Why the extra struct in the first place? Why not simply put a pointer > > to the userspace buffer into the struct v4l2_buffer? > > OK - this was an attempt to work around a weakness in the original API. Hmm. IMHO the original API should be fixed then. Doing it that way also means that the capture interface looks different for userland buffers and mmap()'ed buffers. I don't think that this is a good idea. > The original API requires planar captures to be in a contiguous chunk of > memory with the same bytesperline for all planes. Or bytesperline == 0 which means no padding (which is IMHO the only useful thing for planar modes). > I have seen quite a > few apps for which this is not true - hence the extra structure to allow > the user app to pass a detailed description of where and how to dma the > data. Having a pointer for each plane is fine IMHO. What about padding? I don't think it is useful for planar modes. For packed pixel modes the bytesperline in v4l2_pix_format is enouth. > The size element is there so the user can map a bigger chunk of > memory than is currently necessary so that the format can be changed > later on. IIRC this isn't allowed in the current v4l2 API. How about this approach: * Don't mmap() every single buffer (for the kernel-buffer case). Instead map one big chunk of memory. * pass around only userspace pointers in v4l2_buffer (instead of the offset). For the kernel-buffer case you'd have call VIDIOC_REQBUFS first, then mmap() the memory. Then call VIDIOC_QUERYBUF, and the driver will fill the pointers in v4l2_buffer. For userland buffers you'd call VIDIOC_REQBUFS, then pass the pointers to your buffers using VIDIOC_QUERYBUF to the driver. For the capture itself no difference will be visible, the application can simply use the pointers in v4l2_buffer directly, and it will simply work. No matter whenever that buffer is userland or mmap()'ed kernel memory. drawback: it breaks backward compatibility... But while we are busy with breaking stuff (*grin*): I think with the approach mentioned above we don't need VIDIOC_QUERYBUF any more. You can pass in userspace buffer pointers in VIDIOC_QBUF and receive your pointers to the right point in the mmap()'ed kernel memory in VIDIOC_DQBUF. For the userland buffer case you are not limited to the same set of buffers then. That might be useful for stuff like capturing to a file by mmap()ing it and let the capture driver write directly to the file mapping. Gerd -- Get back there in front of the computer NOW. Christmas can wait. -- Linus "the Grinch" Torvalds, 24 Dec 2000 on linux-kernel
