Gerd Knorr wrote: > 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. Why is the mmap stuff ifdef'ed out? > 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... Rats, and they were soooo convenient. Right now I would say leave them in, but make it generate a syslog message informing the user that the application is out of date the first time they are used. > * What exactly is the purpose of the v4l2_q_* functions? Any reason > not to use the generic lists (linux/lists.h) instead? v4l2_q functions include locking. I suppose they could be implemented on top of lists, but the current implementation is pretty clean and solid. > * What the select code is good for? Allow the compatibility code to use the v4l2 select ioctl to emulate the v4l1 VIDIOCSYNC ioctl. > * 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, Not really - only if the apps don't check the number of buffers returned by GMBUF (if they do, you get full v4l1 compatibility, but only 1 buffer...) > 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 ... I'm not sure about this one. You probably find that there is some hardware that ca[tures onto on-board memory at some fixed locations? Not really sure, but the flexibility is good. Wouldn't one single block be _worse_ for dma-to-userland? Restricting the user to one big buffer, instead of pointing the driver to multiple independant buffers, or do you plan to differentiate the two techniques (in which case, why kill the ability to mmap multiple buffers)? -justin
