Gerd Knorr wrote: > > On Wed, 6 Sep 2000, Justin Schoeman wrote: > > > 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. > > It isn't *that* simple, as sizeof(void*) might be 32 or 64 bits depending > on the architecture. I'd simply add another field to avoid the ifdef mess > (because you'll need one or two if the reserved fields depending on arch) > Yes, I know, this will break (binary) compatibility of the v4l2 interface. Well, this wouldn't break binary compatibility YET. If we took the second and third reserved fields, we would get our 64 bits for the pointer, and still have one spare 32 bit field, without breaking binary compatibility. > > > 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. > > Yes, of course. Last time I got responses along the lines "multiple opens > makes driver writing harder, that's why it is bad". That's why I wanted > make clear that supporting multiple opens isn't mandatory for the drivers. Well, I have been looking at this for bttv2, and the multiple capturing opens code, is actually a lot cleaner, and only slightly more complex. The only thing I don't like is that at the moment, the capture IRQ scans all opens, to see who wants the next incomming frame, and this could be used mliciously - just open hundreds of capturing opens, and let the kernel waste its time canning them all... Got to figure out a way around that one... > > 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. > > IHMO Bills approach (the driver has to support both, but there are some > helper functions for translating v1 <=> v2 provided by videodev.c) is > better. > > > 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. > > Why you want register two minors? Nothing stops a v4l2 driver to respond > to both v4l1 and v4l2 ioctls. The v4l1 ones can be handled by the driver > itself or simply passed to the helper functions in videodev.c. It can > even handle some ioctls the one and some the other way. I see what you mean. The current system is a lot better We may need to provide a way for v4l2 to handle a v4l1 mmap differently though. -justin
