I've made a first swing at separating out the compatibility layer in videodevX. ftp://ftp.thedirks.org/pub/v4l2/kernel2.4/videodevX/ videodevX-20010416.tgz The compatibility layer is in a separate module called v4l_compat. When loaded it calls a new compatibility layer registration function, v4l2_v4l_compat_register(), in videodevX with its interface. The interface has two methods, translate_ioctl() and fix_offset(). The latter is used in the v4l2_mmap() wrapper. Note: If you install the new one, you will not have v4l->V4L2 compatibility unless you do an explicit modprobe v4l_compat. That can be fixed with either a post-install line in /etc/modules.conf or a request_module() in videodevX, but I haven't done it yet. Gerd Knorr wrote: > Why register? The driver can simply call the functions in the helper > module. More flexible, cleaner, I guess. It can be loaded and unloaded; doesn't have to be made a compile-time option in to the drivers. It can be called from videodevX transparent to the driver. Gerd Knorr wrote: > Bill Dirks wrote: > > I don't think one can "put bits of V4L2 that are better > > into V4L" and end up with a decent, coherent interface. V4L2 > > is arranged differently. > > I agree. Nearly all ioctls work different. I think the only > ones which are completely unchanged are VIDIOC_G_FREQ/VIDIOC_S_FREQ. And even those will probably have to change. The set-top box guys are after me to support multiple tuners. Overlay (preview) support needs much expansion for the set-top box market too. I started working on it here: http://www.thedirks.org/v4l2/proposed/overlay.htm (I've got to tweak the terminology, where you see "plane" think "overlay" or "visual".) > > Once V4L2 is in the kernel, v4l support can later be made > > optonal, and eventually be phased out. > > v4l has been _the_ interface for years. And it probably takes > at least one more year until v4l2 shows up in a stable kernel > (2.6). I don't think we can phase out v4l1 ... Well, I meant phase it out three years later, or somesuch. Bill.
