Bill Dirks wrote: > > Gerd Knorr wrote: > > > 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. > > It is. Sort of. It needed to be allowed for v4l compatibility. It's > discussed in the Driver Writer's Guide, but not in the main API > document. I guess you can say it's optional, but recommended. Of course > the format is limited to the size of the currently allocated buffers. I suppose for userbuffers this could be disallowed then? > > 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. > > The driver only has kernelspace addresses. It can't fill in a userspace > pointer. It doesn't know what mmap() returned. It doesn't need to know - it can simply return the offset into the memory mapped area, and the driver does know the offset. I have a feeling that this will make a lot of things simpler, at no cost to functionality. I especially like the one big mmap idea - it makes resource tracking a lot easier. I suppose breaking the API isn't very good, but now is the time to consider it. If the v4l2 API is ever going to make it into the kernel, we need to make sure that it is going to be as universal and complete as possible. We definitely don't want another bttv API with window dressing like the current v4l API! Yes there are many userland apps out there using this API, but I think they would appreciate the change. Instead of having to store each mmaped pointer in an array, the app could simply store one pointer, and add the offset returned by DQBUF. This could actually simplify applications somewhat. -justin
