On Sat, 09 Sep 2000 wrote Jeroen Vreeken: > >Version 0.6 of the driver now uses semaphores for locking and is a >little bit cleaner. >I have also integrated it into the 2.4.0-test7 source tree and included >a patch for it. >It can be found at: http://motion.technolust.cx/vloopback/ Hi Jeroen, a "v4l loopback driver" implementation was discussed on livid-ati@xxxxxxxxxxxxxx some days ago. I have included the proposed function of the driver (see below). It is a bit different to your implementation but I think both are a valuable addition to V4L. The (new) proposed V4L driver would be very useful to link V4L and the Xvideo extension for multimedia video cards (i.e. ATI All-in-wonder, Matrox Marvel, etc.) which are capable of capturing video streams. A pure V4L driver for such cards is very tricky as they combine graphics cards (XFree86 domain) and capture cards (V4L domain). As vloopback already exists it should not be too difficult to enhance it. What do you think ? Marko ----- Here is the posting "Re: loopback v4l driver (was [livid-ati] My Sin)" on livid-ati: > Hi, > > > Or I would prefer another solution: you taking your time and writing > > "loopback v4l driver" which would solve all our problems with video > > capture and Xv extension. > > This idea sounds interesting, promising and challenging. Could you outline > such a "loopback v4l driver" (what it does or should do) ? Maybe it's already written :)) (I haven't checked recently). Basically it should work like virtual terminal pair. So it creates and entry in /proc (like /proc/video/loopback-master0) Any application (restricted by permission perhaps) can open it and issue an ioctl requesting to create virtual v4l device and giving, say frame size and number of frames the buffer must have. The driver creates v4l device and allocates chunk of kernel space for frames. Then the application that opened loopback-master0 can issue ioctl's providing data (I suggest at first to simply copy it - the overhead isn't that big) And the driver will store these frames in ring buffer - feeding them to any application that opened it as v4l device. There a few similar drivers in the kernel - like virtual framebuffer driver. Unlike those ours will be useful for more than testing. Once the basic functionality is done we can go on improving it: * using mmaped memory instead of ioctl's to transfer frames (perhaps ioctl is used to only report that new frame has been added) * pass v4l configure requests back and force to master application * teach driver to request DMA'able memory so we can setup video device to DMA directly into the buffer (though my feeling is this is completely unnecessary - capture perfomance look to be limited by CPU only when you try to compress on-the-fly and by disk when you write there) A suggested way to implement this driver is to take any existing one, throw out hardware dependent part and implement /proc entry to make v4l requests. I also suggest to take a look at USB camera drivers - they support hotplugging so might have a better way of doing initialization than static bt848 cards. And they will already have a mechanism to setup buffers - as they usually are nothing more than controlling interface - the actual transfer is done by USB subsystem. Vladimir Dergachev
