Gerd Knorr wrote: > > > Agreed. The only provisio being that there must be some way for a > > driver registering by method 2 to say if it is v4l1/v4l2 so that the > > compat layer can initialise for that device. > > IMHO the compatibility layer should'nt be mandatory. I think the best > way to handle that is to have a set of helper functions for code which > likely can be useful for multiple drivers (like translating formats > between v4l1 <=> v4l2) in a compat module. The v4l2 driver can use > all / some / none of these functions. If it wants to use these > functions, it simply calls them. > > Not sure how to handle the ioctl translation best. The problem is where > to do the arg copying from/to userspace. Right now the v4l2 ioctl > translation functions calls v4l2_driver->ioctl(), which is expected to > receive a kernel pointer. With file_operations->ioctl() this obviously > doesn't work any more, because that function is expected to handle > userspace copying itself. We'll have to pass a callback function to > translate_ioctl() somehow. Either directly as argument, or somewhere > in a struct. I don't know... IMHO this is starting to not look very clean anymore. How about simply testing if it is a v4l1 or v4l2 device, and if it is v4l2 do the conversion?? > > We will also need a clean > > method for "alternative" names to id the compatible devices (the > > compatibility layer and actual driver will no longer be able to share > > the same minor number. > > Why? The driver can simply call translate_ioctl() for all ioctls it > doesn't understand. I don't see a need to use another minor for > the v4l1 backward compatibility. 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)? > > I think the base name for the device should also be passed in the > > "register" call - this will make it possible to also free the v4l1 > > drivers from arbitrary restrictions on minor numbers, and allow for more > > sensible devfs names. > > We can't get rid of the minor numbers (yet?). devfs is optional and > still marked experimental, so it must work with the traditional > major/minor scheme too. 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. V4L1 devices can simply pass a null parameter, and get a default name based on their minor number. > > Will also have to look at the "type" parameter, as this changes meaning > > for v4l1/v4l2 - perhaps offset them, and use this to id v4l1/v4l2 > > devices? > > Add a type2 field? I suppose, then a driver could register both v4l1 and v4l2 capabilities without any problems. > > The DMA issue is still a major question - the discussion ended on two > > completely divergent solutions, each with major advantages an > > disadvantages, and no definitive solution... This will need a bit more > > discussion (or possibly a decent all out brawl ;->). > > That's why this is the big todo list item. > > > The byte order problems should be resolved shortly with the definition > > of more video formats for the big endian machines. > > Ack. ??? Why "Ack." ? > > > The vbi stuff can be dropped from v4l2 I think. The current vbi API > > > in 2.4.x is cloned from v4l2, and we certainly don't need exactly the > > > same API twice in the kernel. > > > > No. The only thing that is cloned is "struct vbi_format", > > And two ioctl's to get/set that. So you have VIDIOCGVBIFMT(struct > vbi_format) in v4l1 and VIDIOC_G_FMT(struct v4l2_format) with > type = V4L2_TYPE_VBI in v4l2. I can't see any difference here, > and these are the only vbi-specific ioctls in v4l1/2 ... 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. This will also kill the unified capture architecture in v4l2, and force duplication of chunks of code. > > > What is the status of the other v4l2 API's? codec? effects? Any > > > existing drivers which use these? > > > > There was some work in this direction, but I am not sure what happened > > to it... > > Then these should left out too IMHO. There is no point in having > a unused API in the kernel. And in case someone finds a design bug > while writing a driver it is easier to fix if it is not yet in the > standard kernel. Agreed. -justin
