Again :) + Bring Gerd's V4L2 patches into the official release + Bring Gerd's multiple capturing opens into official spec + New FREQ ioctl for multiple tuners + New fields to /proc filesystem support + User-space buffers, Gerd's patch (?) + Interruptible streams (?) + Add two-plane Y/CbCr formats Gerd Knorr wrote: > > + using user-space buffers for streaming capture > > A patch to do that without breaking binary compatibility is below. On > the other hand I'm not sure whenever it is really a good idea to do > that: > > * It makes drivers and applications more complex. We have three ways > (read, mmap buffers, userland buffers) to do capture then. > > * Very likely not all drivers will support that, userland buffers are > not very efficient for hardware which can not DMA directly to random > > * I see very little use for it. The classic example (MIT-SHM) is the > _only_ application I can think of, and even in this case it will save > > Comments? Looking at your patch, I see no reason not to add it. If nobody wants to use it, then fine. But if someone is creating a application/driver pair and has a compelling reason to use it, then there is a standardized way. I just wonder if there is a system vulerability created by it. If a malicious or broken app frees buffers while the driver is still hodling them. > > + interruptible streams (e.g. one program watching video, other catching > Hmm. Any idea how to do that? return errors on system calls? signals? I was thinking it could be as simple as DQBUF returns a specific error code. > > + add two-plane Y/CbCr pixel formats > One plane Y and one with CrCb interleaved? Yes. > i.e. just one more V4L2_PIX_FMT_xxx? At least two: for 4:2:0 and 4:2:2. Also maybe CbCr vs. CrCb. A lot of graphics cards are supporting these for YCbCr-space overlay, textures and blits. Runs nicely on a dual-pipe accelerator. Bill.
