RE: [RFC 0/2] UVC gadget driver
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. Regards, Robert Lukassen -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] UVC gadget driver
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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] UVC gadget driver
Hi Greg, On Thursday 29 April 2010 09:32:10 Greg KH wrote: On Thu, Apr 29, 2010 at 09:14:03AM +0200, Laurent Pinchart wrote: On Thursday 29 April 2010 05:41:11 Greg KH wrote: On Thu, Apr 29, 2010 at 12:52:57AM +0200, Laurent Pinchart wrote: Hi everybody, Here's a new version of the UVC gadget driver I posted on the list some time ago, rebased on 2.6.34-rc5. The private events API has been replaced by the new V4L2 events API that will be available in 2.6.34 (the code is already available in the v4l-dvb tree on linuxtv.org, and should be pushed to git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git very soon). Further testing of the changes related to the events API is required (this is planned for the next few days). As it seems to be the UVC gadget driver season (Robert Lukassen posted his own implementation - having a different goal - two days ago) What are the different goals here? Shouldn't there just be only one way to implement this, or am I missing something? 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? I think so (although I'm not sure if a userspace application can capture the content of the frame buffer on sync events). , I thought I'd post the patch as an RFC. I'd like the UVC function driver to make it to 2.6.35, comments are more than welcome. It needs to get into my tree _now_ if you are wanting it in .35 Just fyi. Does now mean today, or before next week ? Before next week would be good, as soon as possible is best. I'd like to test the events API changes some more. I'll have time to do this before next week. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] UVC gadget driver
On Thu, Apr 29, 2010 at 09:14:03AM +0200, Laurent Pinchart wrote: Hi Greg, On Thursday 29 April 2010 05:41:11 Greg KH wrote: On Thu, Apr 29, 2010 at 12:52:57AM +0200, Laurent Pinchart wrote: Hi everybody, Here's a new version of the UVC gadget driver I posted on the list some time ago, rebased on 2.6.34-rc5. The private events API has been replaced by the new V4L2 events API that will be available in 2.6.34 (the code is already available in the v4l-dvb tree on linuxtv.org, and should be pushed to git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git very soon). Further testing of the changes related to the events API is required (this is planned for the next few days). As it seems to be the UVC gadget driver season (Robert Lukassen posted his own implementation - having a different goal - two days ago) What are the different goals here? Shouldn't there just be only one way to implement this, or am I missing something? 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? , I thought I'd post the patch as an RFC. I'd like the UVC function driver to make it to 2.6.35, comments are more than welcome. It needs to get into my tree _now_ if you are wanting it in .35 Just fyi. Does now mean today, or before next week ? Before next week would be good, as soon as possible is best. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] UVC gadget driver
Hi Greg, On Thursday 29 April 2010 05:41:11 Greg KH wrote: On Thu, Apr 29, 2010 at 12:52:57AM +0200, Laurent Pinchart wrote: Hi everybody, Here's a new version of the UVC gadget driver I posted on the list some time ago, rebased on 2.6.34-rc5. The private events API has been replaced by the new V4L2 events API that will be available in 2.6.34 (the code is already available in the v4l-dvb tree on linuxtv.org, and should be pushed to git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git very soon). Further testing of the changes related to the events API is required (this is planned for the next few days). As it seems to be the UVC gadget driver season (Robert Lukassen posted his own implementation - having a different goal - two days ago) What are the different goals here? Shouldn't there just be only one way to implement this, or am I missing something? 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). , I thought I'd post the patch as an RFC. I'd like the UVC function driver to make it to 2.6.35, comments are more than welcome. It needs to get into my tree _now_ if you are wanting it in .35 Just fyi. Does now mean today, or before next week ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] UVC gadget driver
On Thu, Apr 29, 2010 at 12:52:57AM +0200, Laurent Pinchart wrote: Hi everybody, Here's a new version of the UVC gadget driver I posted on the list some time ago, rebased on 2.6.34-rc5. The private events API has been replaced by the new V4L2 events API that will be available in 2.6.34 (the code is already available in the v4l-dvb tree on linuxtv.org, and should be pushed to git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git very soon). Further testing of the changes related to the events API is required (this is planned for the next few days). As it seems to be the UVC gadget driver season (Robert Lukassen posted his own implementation - having a different goal - two days ago) What are the different goals here? Shouldn't there just be only one way to implement this, or am I missing something? , I thought I'd post the patch as an RFC. I'd like the UVC function driver to make it to 2.6.35, comments are more than welcome. It needs to get into my tree _now_ if you are wanting it in .35 Just fyi. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
