Hi Robert, On Monday 03 May 2010 10:29:17 Robert Lukassen wrote: > > > > Both drivers act as "webcams". Robert's version exports the local > > > > frame buffer through USB, making the "webcam" capture what's > > > > displayed on the device. My version exposes a V4L2 interface to > > > > userspace, allowing an application on the device to send whatever it > > > > wants over USB (for instance frames captured from a sensor, making > > > > the device a real camera). > > > > > > Ah. So your's has the advantage of being able to do what his does as > > > well, right? > > Our driver has been developed with an explicit goal of being 'transparent' > for user-land. When an application uses a double-buffered framebuffer > device for rendering, ALSA for sound playback and the linux input > framework for input, then it just works. We have in the past also used a > V4L2 like API on the video function, but stepped away from it as the > framebuffer usually is uncached, and reading from the framebuffer is slow. > In the approach you suggest, you'll have to memcpy() from a mmapped > framebuffer to the V4L2 buffer. In the kernel driver, you'll have a copy > of the data from the V4L2 buffer to the payload buffers. In the driver > we've posted, data is copied from the framebuffer using an ordinary > memcpy(), but for specific devices we've replaced that with a DMA memory > copy. In that situation, the CPU doesn't do any copying of data and impact > of streaming out video to a host is very low. > > Laurent's driver is more generic, our's has been tuned to low impact/high > performance. I believe there is value in both approaches, but if you want > to avoid to have two function implementations of the same device class it > would be right to favour Laurent's generality over our tuning. > > Please let me know if you still want me to post a patch for f_vdc as a > separate function implementation. I think having both drivers in mainline makes sense. Robert, do you think some of the code could be shared between both drivers, or are they too different ? We could at least put the UVC probe/commit stream request structure in linux/usb/video.h. The descriptor structures should probably be moved there too. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
