Justin Schoeman wrote: > > It is often desirable to DMA directly into a target buffer. For > example, into offscreen memory of a video card, or maybe the compression > buffers of a codec, etc. The main reason I'm interested is for the > offscreen DMA. Didn't think of that one. Things like this shouldn't however be visible to apps -- it needs to be in libv4l2 etc, or you end up with h/w specific apps; not unlike what happens today with bttv. > > > 5) DMA to userspace example: > > > 1 - set capture format (S_FMT) > > > 2 - request buffers (REQBUFS with V4L2_BUF_REQ_DMA set) > > > 3 - allocate userspace memory for the number of granted buffers. "allocate userspace memory" might not be the best wording when talking about mmaped hw buffers :^) This is what confused me. > > > > is it possible to be granted less buffers than requested? when? > > Sometimes the hardware may only support 2 buffers, or there may not be > enough resources, etc. The resource starvation is what i was thinking of. Obviously there can be driver limitations (though if the hw can dma to random pages then it should be capable of supporting N pages. OTOH what about hw that needs continuous memory? A mmapped hw buffer would be fine, but normal userpace mem wouldn't. Would REQBUFS return success in the former case and failure in the latter? Would seem logical, but how is it expected to know?), but checking for available memory at this point, when it isn't yet allocated doesn't buy you much -- QUERYBUF can still fail later. > > > 4 - call QUERYBUF on each buffer, filling in dmabuf with a pointer to > > so the only difference is that the app instead of the v4l2 layer is > > doing the allocation, right? The advantage? > > Yes. As above. If the main use were to be feeding codecs/framebuffers/textures then i'm not sure this isn't too generic. OTOH it does appear not generic enough if it's supposed to be a universal solution (see above). > > QUERYBUF pins down the userspace buffers? what happens it that fails? > > The app receives an error code, and must handle it gracefully. >From an app POV it would seem the only "graceful" thing to do would be to abort -- it's not like any other scheme is likely to work if we're short on memory. OTOH reducing the # of buffers could work, but then it has to undo everything, free the "successfully" allocated mem and go back to (2), which, remember, already returned success. Doesn't seem like a nice i/f, but could work -- yes. > > How is the amount of mlocked memory limited? > > Not yet handled. Any ideas? This and the question below are related :) I'm not sure if a "capture resource" includes the buffers (it probably shouldn't, having more than one buffer set can make sense, eg webcam+preview both using different output hw), but if multiple opens can mlock some memory each then there can't just be a n-buffers/open limit. Having a global limit on the total amount of memory mlocked that could be shared among all clients might be enough for cooperative clients. > > Are multiple opens > > of the same resource possible? > > Yes, in a way. Multiple opens of a capture card are possible, but only > one open can control a capture resource on the card (the definition of a > capture resource is very loose, and depends on the hardware). > > > > 5 - perform streaming capture. > > > 6 - unmap requested buffers (REQBUFS with count set to 0). > > > > Simply closing the device would be enough too? > > That would also do, but the apps must have control of the release points > for capture resources. You don't want to close the card, and > reconfigure from the beginning just to change the image size. Sure, but the memory must be unlocked when the app closes the device or otherwise gets killed. > > Would the new v4l2_buffer be compatible with the old one? > > Yes. Userland apps could be used in the modified without recompiling. Thanks for the clarification artur
