> So it creates and entry in /proc (like /proc/video/loopback-master0) Hmm, this would involve creating a completely new api for this device, with the current method the standard video4linux api can be used. Wouldn't it make more sense to use this and make only a few (if needed) minor additions? The api will change anyway for v4l <-> v4l2 so this shouldn't be to much trouble. Maybe it will make more sense to use /proc/video for pointing to the various pipes. (And maybe creating them if we run out of them) At the moment the driver will need two copies if you use write<->read, and only one if you use write<->mmap. You could change that to mmap<->mmap and have no copies at all, but that would involve getting some problems. If a program 'reads' using mmap it expects to be able to manipulate the image after SYNC. This would mean that the program feeding the pipe will only be allowed to write while the other is between MCAPTURE and SYNC. I think this waiting will kill performance more than the one copy.... Another limitation is that the size and palette can only be set by the program feeding the pipe. Jeroen
