Re: Using UVC webcam gadget with a real v4l2 device
Hi Bhupesh, On Monday 30 April 2012 18:47:24 Bhupesh SHARMA wrote: On Monday, April 30, 2012 3:51 PM Laurent Pinchart wrote: On Thursday 26 April 2012 13:23:59 Bhupesh SHARMA wrote: Hi Laurent, Sorry to jump-in before your reply on my previous mail, but as I was studying the USERPTR stuff in more detail, I have a few more queries which I believe you can include in your reply as well.. [snip] I am now a bit confused on how the entire system will work now: - Does USERPTR method needs to be supported both in UVC gadget and soc-camera side, or one can still support the MMAP method and the other can now be changed to support USERPTR method and we can achieve a ZERO buffer copy operation using this method? You need USERPTR support on one side only. In practice many (all?) soc- camera drivers require physically contiguous memory, so you will need to use MMAP on the soc-camera side and USERPTR on the UVC gadget side. DMABUF, when merged in the kernel, will be a better solution (but will require all drivers to use vb2). Perfect. So, I plan now to add vb2 support for uvc-gadget and leave soc- camera side to use the mmap stuff. Now, waiting for your pointers for managing the race-conditions in the UVC gadget and also avoiding the memcpy that is happening in the QBUF call on the UVC gadget, before I start the actual work. The memcpy doesn't happen at QBUF time, but when filling the URBs. Avoiding it will be pretty difficult, as the driver needs to add packet headers. I would leave that out for now. Regarding videobuf2 support, the main issue comes from race conditions between stream start, buffer queueing and URB completion. Unlike the UVC host driver where URBs can be resubmitted immediately, the gadget driver can only resubmit URBs (in uvc_video_complete()) when there is data to be sent. Otherwise the URB is put on a free URBs list (video-req_free) and enqueued in uvc_video_pump() the next time a buffer is queued. This requires taking various locks and must thus be considered with care. I'm pretty unhappy with calling video-encode with the queue irqlock held, I would like to change that, but I don't expect to to be an easy task. -- 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: Using UVC webcam gadget with a real v4l2 device
Hi Bhupesh, On Thursday 26 April 2012 13:23:59 Bhupesh SHARMA wrote: Hi Laurent, Sorry to jump-in before your reply on my previous mail, but as I was studying the USERPTR stuff in more detail, I have a few more queries which I believe you can include in your reply as well.. [snip] I am now a bit confused on how the entire system will work now: - Does USERPTR method needs to be supported both in UVC gadget and soc-camera side, or one can still support the MMAP method and the other can now be changed to support USERPTR method and we can achieve a ZERO buffer copy operation using this method? You need USERPTR support on one side only. In practice many (all?) soc-camera drivers require physically contiguous memory, so you will need to use MMAP on the soc-camera side and USERPTR on the UVC gadget side. DMABUF, when merged in the kernel, will be a better solution (but will require all drivers to use vb2). - More specifically, I would like to keep the soc-camera still using MMAP (and hence still using video-buf) and make changes at the UVC gadget side to support USERPTR and videobuf2. Will this work? Please see above :-) - At the application side how should we design the flow in case both support USERPTR, i.e. the buffer needs to be protected from simultaneous access from the UVC gadget driver and soc-camera driver (to ensure that a single buffer can be shared across them). Also in case we keep soc-camera still using MMAP and UVC gadget side supporting USERPTR, how can we share a common buffer across the UVC gadget and soc-camera driver. That's easy. Request the same number of buffers on both sides with REQBUFS, mmap() them to userspace on the soc-camera side, and then use the user pointer to queue them with QBUF on the UVC side. You just need to ensure that a buffer is never enqueued to two drivers at the same time. Wait for buffers to be ready on both sides with select(), and when a buffer is ready dequeue it and requeue it on the other side. - In case of USERPTR method the camera capture hardware should be able to DMA the received data to the user space buffers. Are there any specific requirements on the DMA capability of these use-space buffers (scatter-gather or contiguous?). DMA to userspace is quite hackish. You should use the MMAP method on the soc- camera side. -- 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: Using UVC webcam gadget with a real v4l2 device
Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Monday, April 30, 2012 3:51 PM To: Bhupesh SHARMA Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org; ba...@ti.com; g.liakhovet...@gmx.de Subject: Re: Using UVC webcam gadget with a real v4l2 device Hi Bhupesh, On Thursday 26 April 2012 13:23:59 Bhupesh SHARMA wrote: Hi Laurent, Sorry to jump-in before your reply on my previous mail, but as I was studying the USERPTR stuff in more detail, I have a few more queries which I believe you can include in your reply as well.. [snip] I am now a bit confused on how the entire system will work now: - Does USERPTR method needs to be supported both in UVC gadget and soc-camera side, or one can still support the MMAP method and the other can now be changed to support USERPTR method and we can achieve a ZERO buffer copy operation using this method? You need USERPTR support on one side only. In practice many (all?) soc- camera drivers require physically contiguous memory, so you will need to use MMAP on the soc-camera side and USERPTR on the UVC gadget side. DMABUF, when merged in the kernel, will be a better solution (but will require all drivers to use vb2). Perfect. So, I plan now to add vb2 support for uvc-gadget and leave soc-camera side to use the mmap stuff. Now, waiting for your pointers for managing the race-conditions in the UVC gadget and also avoiding the memcpy that is happening in the QBUF call on the UVC gadget, before I start the actual work. Thanks for your help. Regards, Bhupesh - More specifically, I would like to keep the soc-camera still using MMAP (and hence still using video-buf) and make changes at the UVC gadget side to support USERPTR and videobuf2. Will this work? Please see above :-) - At the application side how should we design the flow in case both support USERPTR, i.e. the buffer needs to be protected from simultaneous access from the UVC gadget driver and soc-camera driver (to ensure that a single buffer can be shared across them). Also in case we keep soc- camera still using MMAP and UVC gadget side supporting USERPTR, how can we share a common buffer across the UVC gadget and soc-camera driver. That's easy. Request the same number of buffers on both sides with REQBUFS, mmap() them to userspace on the soc-camera side, and then use the user pointer to queue them with QBUF on the UVC side. You just need to ensure that a buffer is never enqueued to two drivers at the same time. Wait for buffers to be ready on both sides with select(), and when a buffer is ready dequeue it and requeue it on the other side. - In case of USERPTR method the camera capture hardware should be able to DMA the received data to the user space buffers. Are there any specific requirements on the DMA capability of these use-space buffers (scatter-gather or contiguous?). DMA to userspace is quite hackish. You should use the MMAP method on the soc- camera side. -- 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: Using UVC webcam gadget with a real v4l2 device
Hi Laurent, -Original Message- From: Bhupesh SHARMA Sent: Thursday, April 26, 2012 10:54 AM To: 'Laurent Pinchart' Cc: 'linux-...@vger.kernel.org'; 'linux-media@vger.kernel.org'; 'ba...@ti.com'; 'g.liakhovet...@gmx.de' Subject: RE: Using UVC webcam gadget with a real v4l2 device Hi Laurent, Sorry to jump-in before your reply on my previous mail, but as I was studying the USERPTR stuff in more detail, I have a few more queries which I believe you can include in your reply as well.. -Original Message- From: Bhupesh SHARMA Sent: Wednesday, April 25, 2012 8:37 PM To: 'Laurent Pinchart' Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org; ba...@ti.com; g.liakhovet...@gmx.de Subject: RE: Using UVC webcam gadget with a real v4l2 device Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Tuesday, April 24, 2012 2:26 AM To: Bhupesh SHARMA Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org; ba...@ti.com; g.liakhovet...@gmx.de Subject: Re: Using UVC webcam gadget with a real v4l2 device Hi Bhupesh, On Tuesday 24 April 2012 02:46:22 Bhupesh SHARMA wrote: On Monday, April 23, 2012 7:47 PM Laurent Pinchart wrote: On Monday 23 April 2012 02:24:53 Bhupesh SHARMA wrote: Hi Laurent, I have been doing some experimentation with the UVC webcam gadget along with the UVC user-space application which you have written. The UVC webcam gadget works fine with the user space application handling the CONTROL events and providing DATA events. Now, I wish to interface a real v4l2 device, for e.g. VIVI or more particularly a soc_camera based host and subdev pair. Now, I see that I can achieve this by opening the UVC and V4L2 devices and doing MMAP - REQBUF - QBUF - DQBUF calls on both the devices per the UVC control event received. But this will involve copying the video buffer in the user-space application from v4l2 (_CAPTURE) to uvc (_OUTPUT) domains, which will significantly reduce the video capture performance. Is there a better solution to this issue? Maybe doing something like a RNDIS gadget does with the help of u_ether.c like helper routines. But if I remember well it also requires the BRCTL (Bridge Control Utility) in userspace to route data arriving on usb0 to eth0 and vice- versa. Not sure though, if it does copying of a skb buffer from ethernet to usb domain and vice-versa. To avoid copying data between the two devices you should use USERPTR instead of MMAP on at least one of the two V4L2 devices. The UVC gadget driver doesn't support USERPTR yet though. This shouldn't be too difficult to fix, we need toreplace the custom buffers queue implementation with videobuf2, as has been done in the uvcvideo driver. I was thinking of using the USERPTR method too, but I realized that currently neither UVC webcam gadget nor soc-camera subsystem supports this IO method. They support only MMAP IO as of now :( Both soc-camera and the UVC gadget driver should be ported to videobuf2 to fix the problem. I am now a bit confused on how the entire system will work now: - Does USERPTR method needs to be supported both in UVC gadget and soc-camera side, or one can still support the MMAP method and the other can now be changed to support USERPTR method and we can achieve a ZERO buffer copy operation using this method? - More specifically, I would like to keep the soc-camera still using MMAP (and hence still using video-buf) and make changes at the UVC gadget side to support USERPTR and videobuf2. Will this work? - At the application side how should we design the flow in case both support USERPTR, i.e. the buffer needs to be protected from simultaneous access from the UVC gadget driver and soc-camera driver (to ensure that a single buffer can be shared across them). Also in case we keep soc-camera still using MMAP and UVC gadget side supporting USERPTR, how can we share a common buffer across the UVC gadget and soc-camera driver. - In case of USERPTR method the camera capture hardware should be able to DMA the received data to the user space buffers. Are there any specific requirements on the DMA capability of these use-space buffers (scatter-gather or contiguous?). Can you help me with these queries. Thanks, Bhupesh Regards, Bhupesh I'll try to implement this. Would you then be able to test patches ? For sure, I can test your patches on my setup. I had a quick look, but there's a bit more work than expected. The UVC gadget driver locking scheme needs
RE: Using UVC webcam gadget with a real v4l2 device
Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Tuesday, April 24, 2012 2:26 AM To: Bhupesh SHARMA Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org; ba...@ti.com; g.liakhovet...@gmx.de Subject: Re: Using UVC webcam gadget with a real v4l2 device Hi Bhupesh, On Tuesday 24 April 2012 02:46:22 Bhupesh SHARMA wrote: On Monday, April 23, 2012 7:47 PM Laurent Pinchart wrote: On Monday 23 April 2012 02:24:53 Bhupesh SHARMA wrote: Hi Laurent, I have been doing some experimentation with the UVC webcam gadget along with the UVC user-space application which you have written. The UVC webcam gadget works fine with the user space application handling the CONTROL events and providing DATA events. Now, I wish to interface a real v4l2 device, for e.g. VIVI or more particularly a soc_camera based host and subdev pair. Now, I see that I can achieve this by opening the UVC and V4L2 devices and doing MMAP - REQBUF - QBUF - DQBUF calls on both the devices per the UVC control event received. But this will involve copying the video buffer in the user-space application from v4l2 (_CAPTURE) to uvc (_OUTPUT) domains, which will significantly reduce the video capture performance. Is there a better solution to this issue? Maybe doing something like a RNDIS gadget does with the help of u_ether.c like helper routines. But if I remember well it also requires the BRCTL (Bridge Control Utility) in userspace to route data arriving on usb0 to eth0 and vice- versa. Not sure though, if it does copying of a skb buffer from ethernet to usb domain and vice-versa. To avoid copying data between the two devices you should use USERPTR instead of MMAP on at least one of the two V4L2 devices. The UVC gadget driver doesn't support USERPTR yet though. This shouldn't be too difficult to fix, we need toreplace the custom buffers queue implementation with videobuf2, as has been done in the uvcvideo driver. I was thinking of using the USERPTR method too, but I realized that currently neither UVC webcam gadget nor soc-camera subsystem supports this IO method. They support only MMAP IO as of now :( Both soc-camera and the UVC gadget driver should be ported to videobuf2 to fix the problem. I'll try to implement this. Would you then be able to test patches ? For sure, I can test your patches on my setup. I had a quick look, but there's a bit more work than expected. The UVC gadget driver locking scheme needs to be revisited. I unfortunately won't have time to work on that in the next couple of weeks, and very probably not before end of June. Sorry. If you want to give it a try, I can provide you with some pointers. It's a pity. You are the best person to do it as you have in-depth know -how of both v4l2 and UVC webcam gadget. But I can give it a try if you can provide me some pointers.. BTW, I was exploring GSTREAMER to use the data arriving from soc- camera (v4l2) capture device '/dev/video1' via 'v4l2src' plugin and routing the same to the UVC gadget '/dev/video0' via the 'v4l2sink' plugin. Don't know if this can work cleanly in my setup and whether GSTREAMER actually performs a buffer copy internally. But I will at-least give it a try :) There will definitely be a buffer copy (and actually two copies, as the UVC gadget driver performs a second copy internally) if you don't use USERPTR. That's what I was afraid of. But can you let me know where the gadget driver performs a second copy internally, so that I can also start exploring the USERPTR method using the pointers provided by you.. Regards, Bhupesh -- 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: Using UVC webcam gadget with a real v4l2 device
Hi Laurent, Sorry to jump-in before your reply on my previous mail, but as I was studying the USERPTR stuff in more detail, I have a few more queries which I believe you can include in your reply as well.. -Original Message- From: Bhupesh SHARMA Sent: Wednesday, April 25, 2012 8:37 PM To: 'Laurent Pinchart' Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org; ba...@ti.com; g.liakhovet...@gmx.de Subject: RE: Using UVC webcam gadget with a real v4l2 device Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Tuesday, April 24, 2012 2:26 AM To: Bhupesh SHARMA Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org; ba...@ti.com; g.liakhovet...@gmx.de Subject: Re: Using UVC webcam gadget with a real v4l2 device Hi Bhupesh, On Tuesday 24 April 2012 02:46:22 Bhupesh SHARMA wrote: On Monday, April 23, 2012 7:47 PM Laurent Pinchart wrote: On Monday 23 April 2012 02:24:53 Bhupesh SHARMA wrote: Hi Laurent, I have been doing some experimentation with the UVC webcam gadget along with the UVC user-space application which you have written. The UVC webcam gadget works fine with the user space application handling the CONTROL events and providing DATA events. Now, I wish to interface a real v4l2 device, for e.g. VIVI or more particularly a soc_camera based host and subdev pair. Now, I see that I can achieve this by opening the UVC and V4L2 devices and doing MMAP - REQBUF - QBUF - DQBUF calls on both the devices per the UVC control event received. But this will involve copying the video buffer in the user-space application from v4l2 (_CAPTURE) to uvc (_OUTPUT) domains, which will significantly reduce the video capture performance. Is there a better solution to this issue? Maybe doing something like a RNDIS gadget does with the help of u_ether.c like helper routines. But if I remember well it also requires the BRCTL (Bridge Control Utility) in userspace to route data arriving on usb0 to eth0 and vice- versa. Not sure though, if it does copying of a skb buffer from ethernet to usb domain and vice-versa. To avoid copying data between the two devices you should use USERPTR instead of MMAP on at least one of the two V4L2 devices. The UVC gadget driver doesn't support USERPTR yet though. This shouldn't be too difficult to fix, we need toreplace the custom buffers queue implementation with videobuf2, as has been done in the uvcvideo driver. I was thinking of using the USERPTR method too, but I realized that currently neither UVC webcam gadget nor soc-camera subsystem supports this IO method. They support only MMAP IO as of now :( Both soc-camera and the UVC gadget driver should be ported to videobuf2 to fix the problem. I am now a bit confused on how the entire system will work now: - Does USERPTR method needs to be supported both in UVC gadget and soc-camera side, or one can still support the MMAP method and the other can now be changed to support USERPTR method and we can achieve a ZERO buffer copy operation using this method? - More specifically, I would like to keep the soc-camera still using MMAP (and hence still using video-buf) and make changes at the UVC gadget side to support USERPTR and videobuf2. Will this work? - At the application side how should we design the flow in case both support USERPTR, i.e. the buffer needs to be protected from simultaneous access from the UVC gadget driver and soc-camera driver (to ensure that a single buffer can be shared across them). Also in case we keep soc-camera still using MMAP and UVC gadget side supporting USERPTR, how can we share a common buffer across the UVC gadget and soc-camera driver. - In case of USERPTR method the camera capture hardware should be able to DMA the received data to the user space buffers. Are there any specific requirements on the DMA capability of these use-space buffers (scatter-gather or contiguous?). Regards, Bhupesh I'll try to implement this. Would you then be able to test patches ? For sure, I can test your patches on my setup. I had a quick look, but there's a bit more work than expected. The UVC gadget driver locking scheme needs to be revisited. I unfortunately won't have time to work on that in the next couple of weeks, and very probably not before end of June. Sorry. If you want to give it a try, I can provide you with some pointers. It's a pity. You are the best person to do it as you have in-depth know -how of both v4l2 and UVC webcam gadget. But I can give it a try if you can provide me some pointers.. BTW, I was exploring GSTREAMER to use the data
Re: Using UVC webcam gadget with a real v4l2 device
On Tuesday 24 April 2012 08:36:34 Peter Chen wrote: On Mon, Apr 23, 2012 at 2:24 AM, Bhupesh SHARMA wrote: Hi Laurent, I have been doing some experimentation with the UVC webcam gadget along with the UVC user-space application which you have written. I have tried UVC webcam gadget at Freescale i.mx platform, unfortunately, It can't work properly with my demo application. Would you tell me where I can get Laurent's user-space application? Thanks. Here you go: http://git.ideasonboard.org/uvc-gadget.git -- 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: Using UVC webcam gadget with a real v4l2 device
Hi Bhupesh, On Monday 23 April 2012 02:24:53 Bhupesh SHARMA wrote: Hi Laurent, I have been doing some experimentation with the UVC webcam gadget along with the UVC user-space application which you have written. The UVC webcam gadget works fine with the user space application handling the CONTROL events and providing DATA events. Now, I wish to interface a real v4l2 device, for e.g. VIVI or more particularly a soc_camera based host and subdev pair. Now, I see that I can achieve this by opening the UVC and V4L2 devices and doing MMAP - REQBUF - QBUF - DQBUF calls on both the devices per the UVC control event received. But this will involve copying the video buffer in the user-space application from v4l2 (_CAPTURE) to uvc (_OUTPUT) domains, which will significantly reduce the video capture performance. Is there a better solution to this issue? Maybe doing something like a RNDIS gadget does with the help of u_ether.c like helper routines. But if I remember well it also requires the BRCTL (Bridge Control Utility) in userspace to route data arriving on usb0 to eth0 and vice-versa. Not sure though, if it does copying of a skb buffer from ethernet to usb domain and vice-versa. To avoid copying data between the two devices you should use USERPTR instead of MMAP on at least one of the two V4L2 devices. The UVC gadget driver doesn't support USERPTR yet though. This shouldn't be too difficult to fix, we need to replace the custom buffers queue implementation with videobuf2, as has been done in the uvcvideo driver. I'll try to implement this. Would you then be able to test patches ? -- 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: Using UVC webcam gadget with a real v4l2 device
Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Monday, April 23, 2012 7:47 PM To: Bhupesh SHARMA Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org; ba...@ti.com; g.liakhovet...@gmx.de Subject: Re: Using UVC webcam gadget with a real v4l2 device Hi Bhupesh, On Monday 23 April 2012 02:24:53 Bhupesh SHARMA wrote: Hi Laurent, I have been doing some experimentation with the UVC webcam gadget along with the UVC user-space application which you have written. The UVC webcam gadget works fine with the user space application handling the CONTROL events and providing DATA events. Now, I wish to interface a real v4l2 device, for e.g. VIVI or more particularly a soc_camera based host and subdev pair. Now, I see that I can achieve this by opening the UVC and V4L2 devices and doing MMAP - REQBUF - QBUF - DQBUF calls on both the devices per the UVC control event received. But this will involve copying the video buffer in the user-space application from v4l2 (_CAPTURE) to uvc (_OUTPUT) domains, which will significantly reduce the video capture performance. Is there a better solution to this issue? Maybe doing something like a RNDIS gadget does with the help of u_ether.c like helper routines. But if I remember well it also requires the BRCTL (Bridge Control Utility) in userspace to route data arriving on usb0 to eth0 and vice-versa. Not sure though, if it does copying of a skb buffer from ethernet to usb domain and vice-versa. To avoid copying data between the two devices you should use USERPTR instead of MMAP on at least one of the two V4L2 devices. The UVC gadget driver doesn't support USERPTR yet though. This shouldn't be too difficult to fix, we need to replace the custom buffers queue implementation with videobuf2, as has been done in the uvcvideo driver. I was thinking of using the USERPTR method too, but I realized that currently neither UVC webcam gadget nor soc-camera subsystem supports this IO method. They support only MMAP IO as of now :( I'll try to implement this. Would you then be able to test patches ? For sure, I can test your patches on my setup. BTW, I was exploring GSTREAMER to use the data arriving from soc-camera (v4l2) capture device '/dev/video1' via 'v4l2src' plugin and routing the same to the UVC gadget '/dev/video0' via the 'v4l2sink' plugin. Don't know if this can work cleanly in my setup and whether GSTREAMER actually performs a buffer copy internally. But I will at-least give it a try :) Regards, Bhupesh -- 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: Using UVC webcam gadget with a real v4l2 device
Hi Bhupesh, On Tuesday 24 April 2012 02:46:22 Bhupesh SHARMA wrote: On Monday, April 23, 2012 7:47 PM Laurent Pinchart wrote: On Monday 23 April 2012 02:24:53 Bhupesh SHARMA wrote: Hi Laurent, I have been doing some experimentation with the UVC webcam gadget along with the UVC user-space application which you have written. The UVC webcam gadget works fine with the user space application handling the CONTROL events and providing DATA events. Now, I wish to interface a real v4l2 device, for e.g. VIVI or more particularly a soc_camera based host and subdev pair. Now, I see that I can achieve this by opening the UVC and V4L2 devices and doing MMAP - REQBUF - QBUF - DQBUF calls on both the devices per the UVC control event received. But this will involve copying the video buffer in the user-space application from v4l2 (_CAPTURE) to uvc (_OUTPUT) domains, which will significantly reduce the video capture performance. Is there a better solution to this issue? Maybe doing something like a RNDIS gadget does with the help of u_ether.c like helper routines. But if I remember well it also requires the BRCTL (Bridge Control Utility) in userspace to route data arriving on usb0 to eth0 and vice-versa. Not sure though, if it does copying of a skb buffer from ethernet to usb domain and vice-versa. To avoid copying data between the two devices you should use USERPTR instead of MMAP on at least one of the two V4L2 devices. The UVC gadget driver doesn't support USERPTR yet though. This shouldn't be too difficult to fix, we need toreplace the custom buffers queue implementation with videobuf2, as has been done in the uvcvideo driver. I was thinking of using the USERPTR method too, but I realized that currently neither UVC webcam gadget nor soc-camera subsystem supports this IO method. They support only MMAP IO as of now :( Both soc-camera and the UVC gadget driver should be ported to videobuf2 to fix the problem. I'll try to implement this. Would you then be able to test patches ? For sure, I can test your patches on my setup. I had a quick look, but there's a bit more work than expected. The UVC gadget driver locking scheme needs to be revisited. I unfortunately won't have time to work on that in the next couple of weeks, and very probably not before end of June. Sorry. If you want to give it a try, I can provide you with some pointers. BTW, I was exploring GSTREAMER to use the data arriving from soc-camera (v4l2) capture device '/dev/video1' via 'v4l2src' plugin and routing the same to the UVC gadget '/dev/video0' via the 'v4l2sink' plugin. Don't know if this can work cleanly in my setup and whether GSTREAMER actually performs a buffer copy internally. But I will at-least give it a try :) There will definitely be a buffer copy (and actually two copies, as the UVC gadget driver performs a second copy internally) if you don't use USERPTR. -- 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: Using UVC webcam gadget with a real v4l2 device
On Mon, Apr 23, 2012 at 2:24 AM, Bhupesh SHARMA bhupesh.sha...@st.com wrote: Hi Laurent, I have been doing some experimentation with the UVC webcam gadget along with the UVC user-space application which you have written. I have tried UVC webcam gadget at Freescale i.mx platform, unfortunately, It can't work properly with my demo application. Would you tell me where I can get Laurent's user-space application? Thanks. -- BR, Peter Chen -- 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
