Gerd Knorr wrote: ...snip... > Looks like you started with the 2.2.x videodev.c version, some stuff > which was added in 2.3/4.x is'nt there (very quick scan of the sources). Yeah, I know - I just don't have the resources at the moment to keep full 2.2 and 2.4 kernel trees. I will only do 2.4 when it is officially released. > Before v4l2 can go in some minor issues should be fixed. Once > v4l2 is in the kernel (IMHO 2.5.x stuff, so we have some time...) > the API can't be changed easily, so this should be sorted first. > These come in mind: > > * dma-to-userspace. For v4l1 backward compatibility the drivers > will have to support both kernel and userland buffers anyway, so > I'd extend the v4l2 interface to allow both. Adding a flag > to v4l2_buffer.flags to indicate dma-to-userspace and a > void* to v4l2_buffer for the actual pointer should work I think. > > The application will still have to call VIDIOC_QUERYBUF to register > each of the userland buffers to allow the driver to lock down the > buffers between streamon and streamoff. That is just what those reserved[] fields are for at the end of v4l2_buffer. One of those can be used, and an extra flag field implemented. Thanks to Bill Dirks, it seems v4l2 is very extensible... (And thanks to luck/good planning DMA to userspace will work very well with the current API!) > * multiple opens. I'd like to remove the open limitations (the no-io > opens currently in the API spec). IMHO this is just a documentation > and API spec issue. I would also like to have opens simply lock down the resources they require. > It should be clear which ioctls will aquire + lock down ressources > (and may fail with -EBUSY if someone else uses the device) and > which ones free ressources. For capture this should be the > STREAMON/STREAMOFF ioctls I think, for overlay PREVIEW(0/1) should > do the trick. This goes with the point above... > Allowing multiple opens in the API does'nt mean that all drivers must > support it. I think this should be up to the driver. IMHO it should > be allowed for drivers to support single opens only like todays v4l1 > drivers do. This is allowed in the API as is currently specced. An extra that I was think of was to take out the v4l1 backward compatibility from v4l2, and make a separate module, a pseudo driver which can plug in on a different minor, and provide a v4l1 interface to another driver, and a similar module to provide a v4l2 interface to a v4l1 driver. This way the interfaces could also be done at driver level (ie a driver registers both a v4l1 and a v4l2 interface), to provide optimal performance on both interfaces. Any thoughts? -justin
