> > OK, didn't think of that one. Is there a way for a module to find out > > if a specific symbol is being exported by another module (i.e. can a > > driver look for a translate_ioctl function in module v4l1-compat which > > has been previously loaded)? > > Simply use it (like bttv uses videodev_register for example), the other > module will be loaded automagically by module dependences. Or do you > mean something else? I was thinking along the lines of: If the compatibility module is not loaded, the user doesn't want compatibility, so ignore it... > > Yes, it will still work with the traditional major/minor scheme, but if > > you add a string field as well, then v4l2 devices don't have to use > > v4l1's minor number ranges. > > I can't see any advantages you get ... One of the advantages of v4l2 (especially for serious image processing) is that it is not limmited to the arbitrary minor number ranges - you therefore can't extract the base name from the minor number as v4l1 does. > > > Add a type2 field? > > I suppose, then a driver could register both v4l1 and v4l2 capabilities > > without any problems. > > ... which we need to handle both v4l + v4l2 with the same minor number. > > > > Ack. > > > > ??? Why "Ack." ? > > == I agree. network slang :-) Duh! Minor laguage conflict: Here it represents the choking sound made when trying to eat something very unsavoutry ;-) > > The thing is S_FMT and G_FMT are used for setting other formats too. > > You can't remove S_FMT and G_FMT, so you gain nothing by forcing v4l2 > > drivers to interpret VIDIOCGVBIFMT, etc. instead. > > v4l2 drivers are supported to be backward compatible to v4l, so they have > to interpret VIDIOCGVBIFMT anyway. And I can't see any advantages v4l2 > has here, so why support two different ways to do exactly the same? Actually, only the compatibility layer is supposed to interpret VIDIOCGVBIFMT, although nobody has implemented it yet (in fact, I have never seen an application actually USE VIDIOCGVBIFMT!). -justin
