On Mon, Apr 16, 2001 at 12:25:52PM -0700, Bill Dirks wrote: > 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 I've uploaded my hacks: http://www.strusel007.de/linux/bttv/videodev-2001-04-23.tar.gz I've splitted it into three modules: videodev.c This is largely based on the current kernel's videodev.o It adds a fops element to struct video_device, so every driver can have its own struct file_operations. There is _one_ device struct and _one_ set of register/unregister functions. All drivers have to them, no matter which API they support. Right now there are two ways a driver can use to hook in its functions: either the struct fops, or the old open/close/... function pointers. IHMO the old functions pointers should go away during the 2.5.x cycle (once the update is in the kernel fix the existing drivers, then drop them), so in the long run the struct file_operations version is the only way to register a video4linux driver. v4l2-common.c All the v4l2 API helper functions are moved here. Some of them ifdef'ed out (see below). v4l1-compat.c This is basically Bill's v4l compatibility module. No major changes, it works the same way: If you load it it will register and provide a hook (called by v4l2-common.c) which handles v4l1 API support on the same minor number as the v4l2 device. If you don't load it there is no v4l1 support for v4l2 drivers. skeleton.c Sample driver source code (does nothing useful, just shows how the whole thing works together). Problems/Questions: * virt_to_bus() is gone in 2.4.x. It is not available any more for all architectures (i386 does still work, sparc doesn't for example). You have to use the PCI API (see Documentation/DMA-mapping.txt) instead. Looks like the mm helper functions are obsolete now... * What exactly is the purpose of the v4l2_q_* functions? Any reason not to use the generic lists (linux/lists.h) instead? * What the select code is good for? * What exactly was the reason to have one mmap() call for every buffer instead of one big chunk like in v4l1? As the drivers have to support one big chunk anyway for full v4l1 backward compatibility, why not handle v4l2 the same way? That would make things a bit easier I think. And for dma-to-userland support we have to touch the API anyway ... Comments? Gerd
