Hello *, I'd like to comment on the current v4l <-> v4l2 discussion, because I think that some things are going in the wrong direction at the moment. 1) backward-compatibility layer in v4l2 I still don´t see the need of a v4l-backward compatibility layer in v4l2. To be honest: it's more or a less a 'bttv'-compatility layer, trying to achive that old 'bttv'-applications can run on the new 'bttv2'-driver, keeping all the implicit dependencies and crappy design. I have written both v4l and v4l2-drivers for my saa7146-based hardware. Although I tried to make my v4l-driver as 'bttv' as possible, it never worked with all applications, because the apps used some implicit "features" of 'bttv'. So, will my v4l2 driver work with old v4l-apps using the compatibility layer? Most propably no. Fact is: 'v4l' means 'bttv' in most cases. And that's bad. Again my suggestion is: 2) bringing v4l2 in parallel to v4l into the kernel Why not simply assign a new major number to v4l2 and make some new connections in /dev/? With this, Justin's approach using a "videodevX" would not be needed any more. You could load both "videodev.o" and "videodev2.o" and use your old radio-drivers for v4l and the new v4l2-driver for you video-hardware for example. Bringing new stuff in parallel into the kernel has worked before, just look at the ext / ext2 - filesystem switch. Nobody has said: well, you have to add a compatibilty layer to ext2, so it can work with old ext-partitions as well. It was an complete overhaul, too. As far as I know ext was marked obsolete and later dropped from the kernel when nobody was using it anyway. So, why not do this with v4l2? This would end the endless discussion about adding stuff to the existing and working v4l2-module. Who wants to use v4l can use v4l, but everyone is encouraged to use v4l2. But the release of v4l2 to the public world would not be delayed any more. 3) kiobufs A good thing that should be added as soon as possible. The idea is, that unswappable kernel memory is not locked down any more when the app is not capturing at all or not using the capture buffers at the moment. But there were some questions, that have not been answered in this mailing list yet: What happens if the app releases the memory, although the driver is still doing DMA to it? What about memory in regions that cannot be addressed via DMA? Have these things been solved? 4) multiple opens To support multiple capturing opens is a good thing, when the hardware can really deliver independent data from different sources. For a simple tv-card, multiple capturing opens are a mess. The discussion always states that the format of the capture should be maintained with every open. But what about the other parameters available? My hardware has a tuner, 7 different audio inputs and 5 different video inputs. (Yes, it's really asymmetrical.) What things do I have to keep, too? Do I have to keep everything, and whenever some app wants to access the hardware, do I have to switch everything over and over? I don't think that multiple capturing opens are worth the effort. If I have different apps that are responsible for capturing in different formats from different sources, they can open the device, specify what they want, do the capture, close the device and then wait for the next action. A script + cron can be used to do this on a regular time basis. Why mess with multiple capturing opens that stay open for a long while? If I am doing serious video editing on the other hand, I simply don't want other applications to mess with my current settings anyway. If multiple capturing opens should be supported, this should be done using a userspace-library anyway. There is no need to add the complexity to every other driver out there -- some simple hooks + userspace library are much better. Ok, these are my thoughts. Any comments are welcome. 8-) CU, Michael.
