> 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. > 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. > 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. > 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? > 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. > > 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 ... > > 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. Gerd
