Hi Laurent, > -----Original Message----- > From: Laurent Pinchart [mailto:laurent.pinchart@xxxxxxxxxxxxxxxx] > Sent: Tuesday, April 24, 2012 2:26 AM > To: Bhupesh SHARMA > Cc: linux-usb@xxxxxxxxxxxxxxx; linux-media@xxxxxxxxxxxxxxx; > balbi@xxxxxx; g.liakhovetski@xxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
