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. > > 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. > 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. Gerd -- Protecting the children is a good way to get a lot of adults who cant stand up for themselves. -- seen in some sig on /.
