Re: [Linux-uvc-devel] Minoru stereo webcam: Auto Control deactivation
Hi Julien, On Thursday 19 March 2009 18:31:00 julien quelen wrote: Hi all, I am using the new Minoru stereo webcam under Linux with the last version of uvcvideo driver. I get simultaneously the two 640x480 videos at 15fps. Thank you very much for the patch Laurent. However, i don't manage to deactivate the auto gain and auto exposure on the two cameras.(I get an error with V4L2_CID_AUTOGAIN and V4L2_CID_EXPOSURE_AUTO ) I also don't manage to tune exposure, or white balance.. Is it possible to do that? V4L2_CID_EXPOSURE_AUTO should be supported. Please describe the error you receive in more details (including application and kernel log messages). Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] Minoru stereo webcam: Auto Control deactivation
Hi all, I am using the new Minoru stereo webcam under Linux with the last version of uvcvideo driver. I get simultaneously the two 640x480 videos at 15fps. Thank you very much for the patch Laurent. However, i don't manage to deactivate the auto gain and auto exposure on the two cameras.(I get an error with V4L2_CID_AUTOGAIN and V4L2_CID_EXPOSURE_AUTO ) I also don't manage to tune exposure, or white balance.. Is it possible to do that? Thanks in advance! Regards Julien Quelen ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Hi Yann, On Monday 02 March 2009 04:26:25 Yann LeCun wrote: I don't think people really need to the slower framerates, so leaving things as they are for the time being is fine. Still, people should probably be aware of the problem. I've added a note on the linux-uvc website. Best regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Hi Yann, sorry for the late answer. On Tuesday 17 February 2009 00:30:37 Yann LeCun wrote: I seem to be having a strange problem with the patch: Using my own v4l2 grabbing code, I can do: 640x480 15 fps 320x240 30 fps 160x120 30 fps and everything works fine. but if I try 320x240 or 160x120 with an fps any lower than 30 fps, it doesn't work. It looks like my code hangs at the next i/o (or perhaps the next call to select() that it encounters) after grabbing a frame. This problem doesn't happen if I set the fps to 30 (or more). I guess the driver fails to compute an appropriate bandwidth for the resolutions and frame rates. The workaround I've added to the driver is really a heuristic. It computes the required bandwidth by multiplying the frame size (in bytes) by the frame rate and dividing the result by the number of USB isochronous frames (that's roughly the number of isochronous packets) per second. To implement a more precise bandwidth computation algorithm I would have to know what bandwidth the chipset really needs. As I don't have access to that information I'm stuck with guessing. Are small frame rates at small resolutions that important ? If not I'd be tempted to leave things as they are. Best regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
I don't think people really need to the slower framerates, so leaving things as they are for the time being is fine. Still, people should probably be aware of the problem. -- Yann On Sunday 01 March 2009, Laurent Pinchart wrote: Hi Yann, sorry for the late answer. On Tuesday 17 February 2009 00:30:37 Yann LeCun wrote: I seem to be having a strange problem with the patch: Using my own v4l2 grabbing code, I can do: 640x480 15 fps 320x240 30 fps 160x120 30 fps and everything works fine. but if I try 320x240 or 160x120 with an fps any lower than 30 fps, it doesn't work. It looks like my code hangs at the next i/o (or perhaps the next call to select() that it encounters) after grabbing a frame. This problem doesn't happen if I set the fps to 30 (or more). I guess the driver fails to compute an appropriate bandwidth for the resolutions and frame rates. The workaround I've added to the driver is really a heuristic. It computes the required bandwidth by multiplying the frame size (in bytes) by the frame rate and dividing the result by the number of USB isochronous frames (that's roughly the number of isochronous packets) per second. To implement a more precise bandwidth computation algorithm I would have to know what bandwidth the chipset really needs. As I don't have access to that information I'm stuck with guessing. Are small frame rates at small resolutions that important ? If not I'd be tempted to leave things as they are. Best regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Laurent, Laurent Pinchart wrote: Hi Jan, You're right. I've attached an updated version of the patch to this e-mail. Could you please test it ? Will do later today when I am back from office. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJmTKdn11XseNj94gRAqIbAKDZX7xvP/dlQgjDMLSorecDFMFNugCfY6Q8 BHYYHeaz5qeIZJ42CdG53aA= =AChB -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Replying to self: Jan Ciger wrote: Is it actually possible to have two cameras on USB 2.0 bus streaming at 30 fps and VGA resolution? It certainly does work on FireWire 400 - that should have comparable bandwidth in YUV411 mode (have two such Unibrain cams on my desk right now). Actually, I have checked the Minoru camera and it reports the mode as YUV422, not 411. 422 doesn't work in 30fps even on FireWire, so this issue is moot. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJmZvGn11XseNj94gRAhF8AJ42QKV5w64Z3e7YXNImmeG+oOjv1ACg8fFD JbCfQn62YJ7DK8Fk+/uM8oQ= =UZsC -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Laurent, Laurent Pinchart wrote: You're right. I've attached an updated version of the patch to this e-mail. Could you please test it ? I have tested your new patch and now I am able to stream from both cameras at 640x480 and 15fps. 30fps is still giving the no space on device message when I try to open the second camera. The payload sizes reported are 1152 bytes for 15 fps case and 2380 bytes for 30 fps. Is it actually possible to have two cameras on USB 2.0 bus streaming at 30 fps and VGA resolution? It certainly does work on FireWire 400 - that should have comparable bandwidth in YUV411 mode (have two such Unibrain cams on my desk right now). Other than this, the camera seems to start being usable, good job! Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJmZiFn11XseNj94gRAqHTAKDMqWYdwNTyk5EyUWPArA/GEaFtmgCfbpqg R2tZc4MqjmcxF99ckSX3Gk0= =tmOI -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Hi Jan, On Monday 16 February 2009 17:47:01 Jan Ciger wrote: Hello Laurent, Laurent Pinchart wrote: You're right. I've attached an updated version of the patch to this e-mail. Could you please test it ? I have tested your new patch and now I am able to stream from both cameras at 640x480 and 15fps. 30fps is still giving the no space on device message when I try to open the second camera. The payload sizes reported are 1152 bytes for 15 fps case and 2380 bytes for 30 fps. Is it actually possible to have two cameras on USB 2.0 bus streaming at 30 fps and VGA resolution? It certainly does work on FireWire 400 - that should have comparable bandwidth in YUV411 mode (have two such Unibrain cams on my desk right now). Short answer, I don't know. The cameras need to transfer 2380 bytes of video data per microframe. The 12 bytes headers are currently not taken into account by the driver, adding them would raise the total to 2392 bytes per microframe per camera. The smallest bandwidth alternate setting that would still allow us to stream 2380+12 bytes per microframe has an endpoint maximum packed size of 2688 bytes. This would lead to 5376 bytes per microframe for both devices. Periodic transfers can't take more than 80% of the available bandwidth. If we neglect overhead, the maximum periodic transfer length is 480e6 / 8 / 8000 * 0.8 = 6000 bytes per microframe. 5376 bytes seem to fit in the available bandwidth, but we need to take overhead into account, as well as other periodic transfers (interrupt). As the USB core rejects our request for twice 2380 bytes per microframe, I'm inclined to believe 2x 640x...@30fps YUYV can't be streamed on high-speed USB. Other than this, the camera seems to start being usable, good job! Thanks. Unless you believe 30 fps should be supported, I'll take the header size into account and I'll commit the patch. Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Cool! Just to make sure: the patch is meant to be applied to the standard 2.6.27-xx source tree, not to the latest/greatest version of uvc from http://linuxtv.org/hg/~pinchartl/uvcvideo right? by the way, this will probably fix a similar problem I was having while trying to grab images from two Logitech webcams simultaneously. -- Yann On Monday 16 February 2009, Jan Ciger wrote: Replying to self: Jan Ciger wrote: Is it actually possible to have two cameras on USB 2.0 bus streaming at 30 fps and VGA resolution? It certainly does work on FireWire 400 - that should have comparable bandwidth in YUV411 mode (have two such Unibrain cams on my desk right now). Actually, I have checked the Minoru camera and it reports the mode as YUV422, not 411. 422 doesn't work in 30fps even on FireWire, so this issue is moot. Jan ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Laurent Pinchart wrote: 5376 bytes seem to fit in the available bandwidth, but we need to take overhead into account, as well as other periodic transfers (interrupt). As the USB core rejects our request for twice 2380 bytes per microframe, I'm inclined to believe 2x 640x...@30fps YUYV can't be streamed on high-speed USB. Thanks for the explanation, this looks reasonable :( Unfortunately that will make my life a bit more complicated, but well .. Unless you believe 30 fps should be supported, I'll take the header size into account and I'll commit the patch. Well, if there is no way how to get this to work, there is no point in delaying the patch. I am sure the camera doesn't stream 30 fps in Windows neither. Thanks, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJmahTn11XseNj94gRAoAwAJ0eURr6Y/JTseiYNOIjz+q0IKenEACgvZUU sioAKtqb/U04fpwHkD9abTI= =7/fG -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yann LeCun wrote: Cool! Just to make sure: the patch is meant to be applied to the standard 2.6.27-xx source tree, not to the latest/greatest version of uvc from http://linuxtv.org/hg/~pinchartl/uvcvideo right? Nope, this was to the latest UVC. It doesn't apply cleanly to 2.6.27.xxx Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJmainn11XseNj94gRAgzmAJ9IuwkSAvYOC0oKJgf5azqKl1+J1wCg3TPa 4Wd78rKM0BW1efaZ1qn9bTQ= =gvQ0 -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
OK, the patch works for me too. The Minoru works like a charm now. 640x480 at 15 fps works fine. 640x480 at 30 fps doesn't work, as Jan noted. the raw bandwidth for 2 cameras at 640x480, 30 fps, in YUYV (two bytes per pixel) is just below the USB bandwidth, but the overhead must make it go over. Laurent: merci mille fois. -- Yann On Monday 16 February 2009, Jan Ciger wrote: Yann LeCun wrote: Cool! Just to make sure: the patch is meant to be applied to the standard 2.6.27-xx source tree, not to the latest/greatest version of uvc from http://linuxtv.org/hg/~pinchartl/uvcvideo right? Nope, this was to the latest UVC. It doesn't apply cleanly to 2.6.27.xxx Regards, Jan ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
I seem to be having a strange problem with the patch: Using my own v4l2 grabbing code, I can do: 640x480 15 fps 320x240 30 fps 160x120 30 fps and everything works fine. but if I try 320x240 or 160x120 with an fps any lower than 30 fps, it doesn't work. It looks like my code hangs at the next i/o (or perhaps the next call to select() that it encounters) after grabbing a frame. This problem doesn't happen if I set the fps to 30 (or more). Very strange. -- Yann On Monday 16 February 2009, Jan Ciger wrote: Laurent Pinchart wrote: 5376 bytes seem to fit in the available bandwidth, but we need to take overhead into account, as well as other periodic transfers (interrupt). As the USB core rejects our request for twice 2380 bytes per microframe, I'm inclined to believe 2x 640x...@30fps YUYV can't be streamed on high-speed USB. Thanks for the explanation, this looks reasonable :( Unfortunately that will make my life a bit more complicated, but well .. Unless you believe 30 fps should be supported, I'll take the header size into account and I'll commit the patch. Well, if there is no way how to get this to work, there is no point in delaying the patch. I am sure the camera doesn't stream 30 fps in Windows neither. Thanks, Jan ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Hi Jan, On Sunday 15 February 2009 05:46:09 Jan Ciger wrote: Laurent Pinchart wrote: Hi everybody, ... Hello Laurent, I have tried the patch against the driver in Mandriva's 2.6.27 (2.6.27.14-server-1.uc2mnb) and it didn't apply cleanly. After fixing the rejects the driver worked, but I was unable to stream the video from both cameras. I was getting no space on device error as before. Could you try different resolutions ? The driver should report the bandwidth requested by the camera in the kernel log, that information can help debugging the issue. Afterwards I have downloaded the latest uvc driver from the repository, applied the patch (cleanly this time) and tried to load the driver. The driver loads, recognizes the camera but when I try to start luvcview, I get the attached kernel crash :( Which kernel is your driver supposed to work with? It's supposed to be compatible with all kernels starting at 2.6.16. Please note that you must use the videodev module (and its dependencies) from the uvcvideo source tree. Mixing uvcvideo from the mercurial tree with a mainline videodev module will probably crash. Best regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Laurent, Laurent Pinchart wrote: Hi Jan, Could you try different resolutions ? The driver should report the bandwidth requested by the camera in the kernel log, that information can help debugging the issue. OK, got it work now - I guess I have mixed some incompatible module versions. 320x240 15 and 30fps works, both cameras stream. Log shows: uvcvideo: device Vimicro USB2.0 PC Camera requested 595 bytes per payload. 352x288 15 and 30fps works, both cameras stream Log: uvcvideo: device Vimicro USB2.0 PC Camera requested 785 bytes per payload. 640x480 15 and 30fps doesn't work, opening second luvcview results in: uvcvideo: device Vimicro USB2.0 PC Camera requested 2380 bytes per payload. uvcvideo: Failed to submit URB 0 (-28). Strange thing is that the amount of data requested doesn't depend on the frame rate. I did a bit of experimentation and have managed to get both cameras stream at 640x480/15fps with the payload size of 2000 bytes. However, luvcview hangs if I try to use 30fps (there is no message in the log). I think you need to take the requested framerate in the account when doing the calculation. Please note that you must use the videodev module (and its dependencies) from the uvcvideo source tree. Mixing uvcvideo from the mercurial tree with a mainline videodev module will probably crash. Yep - that was it :( Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJmECcn11XseNj94gRAuJkAJ0YQy+B1wL0M8i7rCZbC//dQnOtjQCgnTyM FXjydE+KeTkSxfLwF0bGE9o= =crOr -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Hi Jan, On Sunday 15 February 2009 17:19:42 Jan Ciger wrote: Hi Laurent, Laurent Pinchart wrote: Hi Jan, Could you try different resolutions ? The driver should report the bandwidth requested by the camera in the kernel log, that information can help debugging the issue. OK, got it work now - I guess I have mixed some incompatible module versions. 320x240 15 and 30fps works, both cameras stream. Log shows: uvcvideo: device Vimicro USB2.0 PC Camera requested 595 bytes per payload. 352x288 15 and 30fps works, both cameras stream Log: uvcvideo: device Vimicro USB2.0 PC Camera requested 785 bytes per payload. 640x480 15 and 30fps doesn't work, opening second luvcview results in: uvcvideo: device Vimicro USB2.0 PC Camera requested 2380 bytes per payload. uvcvideo: Failed to submit URB 0 (-28). Strange thing is that the amount of data requested doesn't depend on the frame rate. I did a bit of experimentation and have managed to get both cameras stream at 640x480/15fps with the payload size of 2000 bytes. However, luvcview hangs if I try to use 30fps (there is no message in the log). I think you need to take the requested framerate in the account when doing the calculation. You're right. I've attached an updated version of the patch to this e-mail. Could you please test it ? Please note that you must use the videodev module (and its dependencies) from the uvcvideo source tree. Mixing uvcvideo from the mercurial tree with a mainline videodev module will probably crash. Yep - that was it :( Best regards, Laurent Pinchart diff -r 62db428e724f linux/drivers/media/video/uvc/uvc_driver.c --- a/linux/drivers/media/video/uvc/uvc_driver.c Sat Feb 14 23:39:08 2009 +0100 +++ b/linux/drivers/media/video/uvc/uvc_driver.c Sun Feb 15 19:54:47 2009 +0100 @@ -1863,6 +1863,15 @@ .bInterfaceSubClass = 1, .bInterfaceProtocol = 0, .driver_info = UVC_QUIRK_STREAM_NO_FID }, + /* ViMicro */ + { .match_flags = USB_DEVICE_ID_MATCH_VENDOR +| USB_DEVICE_ID_MATCH_INT_INFO, + .idVendor = 0x0ac8, + .idProduct = 0x, + .bInterfaceClass = USB_CLASS_VIDEO, + .bInterfaceSubClass = 1, + .bInterfaceProtocol = 0, + .driver_info = UVC_QUIRK_FIX_BANDWIDTH }, /* MT6227 */ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO, diff -r 62db428e724f linux/drivers/media/video/uvc/uvc_video.c --- a/linux/drivers/media/video/uvc/uvc_video.c Sat Feb 14 23:39:08 2009 +0100 +++ b/linux/drivers/media/video/uvc/uvc_video.c Sun Feb 15 19:54:48 2009 +0100 @@ -84,6 +84,24 @@ video-dev-uvc_version 0x0110)) ctrl-dwMaxVideoFrameSize = frame-dwMaxVideoFrameBufferSize; + + if (video-dev-quirks UVC_QUIRK_FIX_BANDWIDTH + video-streaming-intf-num_altsetting 1) { + u32 interval; + u32 bandwidth; + + interval = (ctrl-dwFrameInterval 10) + ? ctrl-dwFrameInterval + : frame-dwFrameInterval[0]; + + bandwidth = frame-wWidth * frame-wHeight / 8 * format-bpp; + bandwidth *= 1000 / interval + 1; + bandwidth /= 1000; + if (video-dev-udev-speed == USB_SPEED_HIGH) + bandwidth /= 8; + + ctrl-dwMaxPayloadTransferSize = bandwidth; + } } static int uvc_get_video_ctrl(struct uvc_video_device *video, @@ -900,6 +918,9 @@ bandwidth, defaulting to lowest.\n, video-vdev-name); bandwidth = 1; + } else { + uvc_printk(KERN_INFO, device %s requested %u bytes +per payload.\n, video-vdev-name, bandwidth); } for (i = 0; i intf-num_altsetting; ++i) { diff -r 62db428e724f linux/drivers/media/video/uvc/uvcvideo.h --- a/linux/drivers/media/video/uvc/uvcvideo.h Sat Feb 14 23:39:08 2009 +0100 +++ b/linux/drivers/media/video/uvc/uvcvideo.h Sun Feb 15 19:54:48 2009 +0100 @@ -315,6 +315,7 @@ #define UVC_QUIRK_STREAM_NO_FID 0x0010 #define UVC_QUIRK_IGNORE_SELECTOR_UNIT 0x0020 #define UVC_QUIRK_PRUNE_CONTROLS 0x0040 +#define UVC_QUIRK_FIX_BANDWIDTH 0x0080 /* Format flags */ #define UVC_FMT_FLAG_COMPRESSED 0x0001 ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Hi everybody, here's a patch to fix the USB bandwidth value for Vimicro cameras. The required bandwidth is computed from the frame size (width * height * bpp / 8), the minimum frame interval and the USB (micro-)frame duration. If you own a Vimicro device, could you please test the patch and report results ? I'm especially interested in reports from streaming from two Vimicro devices at the same time (if you own a Minoru3D you have no excuse not to try this). Simone, could you also test the patch with your camera ? I don't think you've reported the camera model, is it a Vimicro device ? Best regards, Laurent Pinchart diff -r fb6b18688092 linux/drivers/media/video/uvc/uvc_driver.c --- a/linux/drivers/media/video/uvc/uvc_driver.c Sat Feb 14 23:39:08 2009 +0100 +++ b/linux/drivers/media/video/uvc/uvc_driver.c Sun Feb 15 00:44:40 2009 +0100 @@ -1863,6 +1863,15 @@ .bInterfaceSubClass = 1, .bInterfaceProtocol = 0, .driver_info = UVC_QUIRK_STREAM_NO_FID }, + /* ViMicro */ + { .match_flags = USB_DEVICE_ID_MATCH_VENDOR +| USB_DEVICE_ID_MATCH_INT_INFO, + .idVendor = 0x0ac8, + .idProduct = 0x, + .bInterfaceClass = USB_CLASS_VIDEO, + .bInterfaceSubClass = 1, + .bInterfaceProtocol = 0, + .driver_info = UVC_QUIRK_FIX_BANDWIDTH }, /* MT6227 */ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO, diff -r fb6b18688092 linux/drivers/media/video/uvc/uvc_video.c --- a/linux/drivers/media/video/uvc/uvc_video.c Sat Feb 14 23:39:08 2009 +0100 +++ b/linux/drivers/media/video/uvc/uvc_video.c Sun Feb 15 00:44:40 2009 +0100 @@ -84,6 +84,19 @@ video-dev-uvc_version 0x0110)) ctrl-dwMaxVideoFrameSize = frame-dwMaxVideoFrameBufferSize; + + if (video-dev-quirks UVC_QUIRK_FIX_BANDWIDTH + video-streaming-intf-num_altsetting 1) { + u32 bandwidth; + + bandwidth = 1000 / frame-dwFrameInterval[0] + 1; + bandwidth *= frame-wWidth * frame-wHeight / 8 * format-bpp; + bandwidth /= 1000; + if (video-dev-udev-speed == USB_SPEED_HIGH) + bandwidth /= 8; + + ctrl-dwMaxPayloadTransferSize = bandwidth; + } } static int uvc_get_video_ctrl(struct uvc_video_device *video, @@ -900,6 +913,9 @@ bandwidth, defaulting to lowest.\n, video-vdev-name); bandwidth = 1; + } else { + uvc_printk(KERN_INFO, device %s requested %u bytes +per payload.\n, video-vdev-name, bandwidth); } for (i = 0; i intf-num_altsetting; ++i) { diff -r fb6b18688092 linux/drivers/media/video/uvc/uvcvideo.h --- a/linux/drivers/media/video/uvc/uvcvideo.h Sat Feb 14 23:39:08 2009 +0100 +++ b/linux/drivers/media/video/uvc/uvcvideo.h Sun Feb 15 00:44:40 2009 +0100 @@ -315,6 +315,7 @@ #define UVC_QUIRK_STREAM_NO_FID 0x0010 #define UVC_QUIRK_IGNORE_SELECTOR_UNIT 0x0020 #define UVC_QUIRK_PRUNE_CONTROLS 0x0040 +#define UVC_QUIRK_FIX_BANDWIDTH 0x0080 /* Format flags */ #define UVC_FMT_FLAG_COMPRESSED 0x0001 ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Laurent Pinchart wrote: Hi everybody, here's a patch to fix the USB bandwidth value for Vimicro cameras. The required bandwidth is computed from the frame size (width * height * bpp / 8), the minimum frame interval and the USB (micro-)frame duration. If you own a Vimicro device, could you please test the patch and report results ? I'm especially interested in reports from streaming from two Vimicro devices at the same time (if you own a Minoru3D you have no excuse not to try this). I am on it! Will report back ASAP. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJl37Kn11XseNj94gRAuDZAJ4i987vxrALaKcJWw/dmi0x7BlywgCg4BQj tHN2SC5qHoQ92pnWfnjAQsk= =g+ur -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Hi Simone, On Tuesday 03 February 2009, Simone Freddio wrote: Hi Laurent, here the results of my tests: MaxPayloadTransferSizeValue Returned from device Result 0128 uvcvideo: USB isochronous frame lost (-71). 1128 uvcvideo: USB isochronous frame lost (-71). 42 128 uvcvideo: USB isochronous frame lost (-71). 1024 1024 works right with few USB iso frame lost 0x 3072 no error but also no capture :-( My conclusion is that MaxPayloadTransferSize, regardless of specification, is not readonly... seems to be that device round this value to the closest that is supported (see also my lsusb in file lsusb.txt). I think that the right bandwidth allocation must be calculated in the driver and set up in the device (the same you have done for frameinterval value :-). I'll see if I can compute an estimated maximum payload transfer size based on the information available to the driver, otherwise I will just just smaller allocations until one of them succeeds. I should get a Vimicro camera soon that I will use to develop and test the workaround. Best regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Laurent Pinchart wrote: Could you (or Jan) try to set dwMaxPayloadTransferSize to a weird value (let's say 42) and see what the device returns in the next GET_CUR call ? I can give this a shot later today and will report back. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJiAzYn11XseNj94gRAjwdAKCDQSQZg7roZ/yd+fdupmHXEfrwRACg3Q9c +HFiZEpU/q2XzpbRWXcOKtQ= =MkLd -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Hi Laurent, here the results of my tests: MaxPayloadTransferSizeValue Returned from device Result 0128 uvcvideo: USB isochronous frame lost (-71). 1128 uvcvideo: USB isochronous frame lost (-71). 42 128 uvcvideo: USB isochronous frame lost (-71). 1024 1024 works right with few USB iso frame lost 0x 3072 no error but also no capture :-( My conclusion is that MaxPayloadTransferSize, regardless of specification, is not readonly... seems to be that device round this value to the closest that is supported (see also my lsusb in file lsusb.txt). I think that the right bandwidth allocation must be calculated in the driver and set up in the device (the same you have done for frameinterval value :-). BR Simone. Laurent Pinchart wrote: Hi Simone, On Tuesday 03 February 2009, Simone Freddio wrote: Hi Jan, hi Laurent... i have the same problem with different webcam... i think to have found the problem, Laurent tell me if i am wrong, i'll go to explain: The problem is in the bandwidth, the uvcdriver ALWAYS ask to usb layer a dw_MaxPayloadTransferSize that is fetched only when the device is opening; In my case is always set to 3072 (3x1024). I have tried changing uvc_video.c in a very dirty manner (excuse me Laurent) Don't worry :-) in this way: In function 'uvc_set_video_ctrl' where there is: put_unaligned_le32(ctrl-dwMaxVideoFrameSize, data[18]); put_unaligned_le32(ctrl-dwMaxPayloadTransferSize, data[22]); i have commented out the second line and changed it in: put_unaligned_le32(1024, data[22]); In this way i have always force uvc driver to ask for a payload size of 1024. According to the UVC 1.1 specification, the dwMaxPayloadTransferSize is set by the device and read only from the host. The value set by the host shouldn't matter. After recompiling, reinstalling, unload e load the module, i can get two webcam working fine and simultaneously. Now i didn't have a big experience and i can't change source myself in the right way... but i think that my observation can be usefull. It is, thanks. I think that the best way to re-negotiate the bandwidth is to set video streaming parameters (framesize and frameinterval) and after ask the device wich bandwidth it requests. That's exactly what the driver does. In uvc_probe_video, each SET_CUR request is followed by a GET_CUR to retrieve the bandwidth requested by the camera. In a short way, at the end of uvc_set_video_ctrl function a call to uvc_get_video_ctrl will solve the problem... what do you think Laurent?) This is already handled by uvc_probe_video. From your report it seems that the device doesn't touch the dwMaxPayloadTransferSize at all and just returns the value sets by the host. Could you (or Jan) try to set dwMaxPayloadTransferSize to a weird value (let's say 42) and see what the device returns in the next GET_CUR call ? Best regards, Laurent Pinchart Bus 001 Device 005: ID 0ac8:332d Z-Star Microelectronics Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x0ac8 Z-Star Microelectronics Corp. idProduct 0x332d bcdDevice1.00 iManufacturer 1 Vimicro Corp. iProduct2 Vega USB 2.0 Camera. iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 581 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 14 Video bFunctionSubClass 3 Video Interface Collection bFunctionProtocol 0 iFunction 2 Vega USB 2.0 Camera. Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass14 Video bInterfaceSubClass 1 Video Control
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simone Freddio wrote: Hi Laurent, here the results of my tests: MaxPayloadTransferSizeValue Returned from device Result 0128 uvcvideo: USB isochronous frame lost (-71). 1128 uvcvideo: USB isochronous frame lost (-71). 42 128 uvcvideo: USB isochronous frame lost (-71). 1024 1024 works right with few USB iso frame lost 0x 3072 no error but also no capture :-( My conclusion is that MaxPayloadTransferSize, regardless of specification, is not readonly... seems to be that device round this value to the closest that is supported (see also my lsusb in file lsusb.txt). I have tried this too and regardless what I put as the PayloadTransferSize, the Minoru camera will always ask for 3072 back. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJiNCUn11XseNj94gRAg/gAJ0dORAwgwUJ0EYqA9O0vG0XgBtGDgCdHXCx 0igBKNMX3tSawbs0+L4hz/M= =ok3d -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Laurent Pinchart wrote: That's bad. The USB EHCI driver will reject 2x 3072 bytes per microframe as exceeding the available bandwidth. Yep, I suspected something like that ... I suppose you'll object that the cameras work on Windows, so I'll try to address that :-) Thank you :) I see three possible reasons why Windows would stream video from both cameras at the same time. - The Windows UVC driver might query the cameras slightly differently and receive a different bandwidth. A USB sniffer would help confirm or infirm this explanation. I can check this if I manage to get a sniffer to work. I will report back once that far. - The Windows UVC driver might ignore the requested bandwidth and compute a value itself. - Windows might accept 2x 3072 bytes per microframe. I seem to remember this might be the case, and that that behaviour is buggy according to the USB 2.0 spec. You would have to contact the linux-usb mailing list for more information on that. Hard to say which one is correct. It could be even both - Windows accepts the value (doesn't report error) and the driver does some kind of black magic afterwards to get things actually working. I am getting different resolutions offered on Windows than on Linux and also the camera seems to run at a lower framerate if both cameras are streaming. I didn't try to measure it, but the stereo output looks like ~10fps or so. It could be a software issue as well, though. The documentation is also cautioning to plug the device ideally to a separate host and not to use the USB connectors on the front panel - they assume that those are not full-featured. So it could be indeed a marginal design. It would be helpful if you could capture all USB control traffic from device enumeration to video streaming using a USB analyser (a software one will do). It would show what bandwidth the device requests, and what bandwidth the Windows UVC driver selects. As I said above, I will try to get a sniffer working and will report back once that far. Regards (and thanks), Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJhz2+n11XseNj94gRAlm+AKDOTMtUwPvAFW4sqLmLc+DhGzcXvgCeIuJP /Pq16p2jarKlLMQdVtCJmbI= =NsvL -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Hi Jan, hi Laurent... i have the same problem with different webcam... i think to have found the problem, Laurent tell me if i am wrong, i'll go to explain: The problem is in the bandwidth, the uvcdriver ALWAYS ask to usb layer a dw_MaxPayloadTransferSize that is fetched only when the device is opening; In my case is always set to 3072 (3x1024). I have tried changing uvc_video.c in a very dirty manner (excuse me Laurent) in this way: In function 'uvc_set_video_ctrl' where there is: put_unaligned_le32(ctrl-dwMaxVideoFrameSize, data[18]); put_unaligned_le32(ctrl-dwMaxPayloadTransferSize, data[22]); i have commented out the second line and changed it in: put_unaligned_le32(1024, data[22]); In this way i have always force uvc driver to ask for a payload size of 1024. After recompiling, reinstalling, unload e load the module, i can get two webcam working fine and simultaneously. Now i didn't have a big experience and i can't change source myself in the right way... but i think that my observation can be usefull. I think that the best way to re-negotiate the bandwidth is to set video streaming parameters (framesize and frameinterval) and after ask the device wich bandwidth it requests. In a short way, at the end of uvc_set_video_ctrl function a call to uvc_get_video_ctrl will solve the problem... what do you think Laurent?) BR Simone P.S.: Excuse me for my english Jan Ciger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Laurent Pinchart wrote: That's bad. The USB EHCI driver will reject 2x 3072 bytes per microframe as exceeding the available bandwidth. Yep, I suspected something like that ... I suppose you'll object that the cameras work on Windows, so I'll try to address that :-) Thank you :) I see three possible reasons why Windows would stream video from both cameras at the same time. - The Windows UVC driver might query the cameras slightly differently and receive a different bandwidth. A USB sniffer would help confirm or infirm this explanation. I can check this if I manage to get a sniffer to work. I will report back once that far. - The Windows UVC driver might ignore the requested bandwidth and compute a value itself. - Windows might accept 2x 3072 bytes per microframe. I seem to remember this might be the case, and that that behaviour is buggy according to the USB 2.0 spec. You would have to contact the linux-usb mailing list for more information on that. Hard to say which one is correct. It could be even both - Windows accepts the value (doesn't report error) and the driver does some kind of black magic afterwards to get things actually working. I am getting different resolutions offered on Windows than on Linux and also the camera seems to run at a lower framerate if both cameras are streaming. I didn't try to measure it, but the stereo output looks like ~10fps or so. It could be a software issue as well, though. The documentation is also cautioning to plug the device ideally to a separate host and not to use the USB connectors on the front panel - they assume that those are not full-featured. So it could be indeed a marginal design. It would be helpful if you could capture all USB control traffic from device enumeration to video streaming using a USB analyser (a software one will do). It would show what bandwidth the device requests, and what bandwidth the Windows UVC driver selects. As I said above, I will try to get a sniffer working and will report back once that far. Regards (and thanks), Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJhz2+n11XseNj94gRAlm+AKDOTMtUwPvAFW4sqLmLc+DhGzcXvgCeIuJP /Pq16p2jarKlLMQdVtCJmbI= =NsvL -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Hi Simone, On Tuesday 03 February 2009, Simone Freddio wrote: Hi Jan, hi Laurent... i have the same problem with different webcam... i think to have found the problem, Laurent tell me if i am wrong, i'll go to explain: The problem is in the bandwidth, the uvcdriver ALWAYS ask to usb layer a dw_MaxPayloadTransferSize that is fetched only when the device is opening; In my case is always set to 3072 (3x1024). I have tried changing uvc_video.c in a very dirty manner (excuse me Laurent) Don't worry :-) in this way: In function 'uvc_set_video_ctrl' where there is: put_unaligned_le32(ctrl-dwMaxVideoFrameSize, data[18]); put_unaligned_le32(ctrl-dwMaxPayloadTransferSize, data[22]); i have commented out the second line and changed it in: put_unaligned_le32(1024, data[22]); In this way i have always force uvc driver to ask for a payload size of 1024. According to the UVC 1.1 specification, the dwMaxPayloadTransferSize is set by the device and read only from the host. The value set by the host shouldn't matter. After recompiling, reinstalling, unload e load the module, i can get two webcam working fine and simultaneously. Now i didn't have a big experience and i can't change source myself in the right way... but i think that my observation can be usefull. It is, thanks. I think that the best way to re-negotiate the bandwidth is to set video streaming parameters (framesize and frameinterval) and after ask the device wich bandwidth it requests. That's exactly what the driver does. In uvc_probe_video, each SET_CUR request is followed by a GET_CUR to retrieve the bandwidth requested by the camera. In a short way, at the end of uvc_set_video_ctrl function a call to uvc_get_video_ctrl will solve the problem... what do you think Laurent?) This is already handled by uvc_probe_video. From your report it seems that the device doesn't touch the dwMaxPayloadTransferSize at all and just returns the value sets by the host. Could you (or Jan) try to set dwMaxPayloadTransferSize to a weird value (let's say 42) and see what the device returns in the next GET_CUR call ? Best regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have also got the Minoru stereo webcam, the same as described by Yann on 31.1. and with the same problem (unable to stream from both cameras at once), regardless of which USB port is used. It doesn't work even if the camera is attached to a separate USB controller with nothing else on it. The webcam contains actually two Vimicro cameras connected to an internal USB hub, together with a USB microphone. In Windows on the same machine it works OK, albeit a bit slow (framerate throttling?). I have tried to reduce the framerate (only 30 and 15fps are supported) and all resolutions besides the 640x480 maximum (the Windows driver claims 800x600, but that looks interpolated) and still the second camera will not stream if the first one is already doing so. Is there a way to get two UVC cameras to stream at the same time? Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJhgbnn11XseNj94gRAnbmAKCCZ7bQs17hK7w+0TU9TKQnoUXtRACg3LeM tDpg1CdD3YX9sAWQJFczvmw= =8wul -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
Hi Yann, On Saturday 31 January 2009, Yann LeCun wrote: Laurent and all, I just got one of those new Minoru stereo webcams. At 90 bucks from Amazon, the Minoru is several times cheaper than any alternative, and there are lots of cool things you could do with a stereo camera under Linux (see http://www.minoru3d.com/ ). The good news is that uvcvideo recognizes the stereo camera as two separate cameras (which appear as /dev/video0 and /dev/video1 in my laptop with Ubuntu 8.10). I can grab video from the left and right camera separately with no problem. I'm using the standard uvcvideo driver that comes with Ubuntu 8.10 Intrepid. The problem is that I cannot seem to be able to grab from both cameras simultaneously. If I turn on streaming on one camera, the second camera refuses to turn on streaming. In other words ioctl(fd, VIDIOC_STREAMON, type) with type = V4L2_BUF_TYPE_VIDEO_CAPTURE fails (it returns -2). dmesg says: uvcvideo: Failed to submit URB 0 (-28). Similarly, if I have luvcview running on one camera and I try to start luvcview on the other camera, I get the error message: Unable to start capture: No space left on device I suspect this is a problem with the USB bus bandwidth. That's right. The webcams request more bandwidth than the USB can allocate (or the driver mistakenly believes so). The problem with luvcview occurs even if I reduce the resolution to 160x120 with luvcview -d /dev/video0 -s 160x120 Is there an easy fix? A difficult fix? Could you please apply the attached patch ? It adds a print statement to log the requested bandwidth when starting the video stream. Please check the kernel log (using dmesg) after starting luvcview in various resolutions and report the requested bandwidths. Best regards, Laurent Pinchart diff -r a98f3ecba7a1 linux/drivers/media/video/uvc/uvc_video.c --- a/linux/drivers/media/video/uvc/uvc_video.c Sun Jan 18 21:46:30 2009 +0100 +++ b/linux/drivers/media/video/uvc/uvc_video.c Sun Feb 01 22:50:47 2009 +0100 @@ -897,6 +897,9 @@ bandwidth, defaulting to lowest.\n, video-vdev-name); bandwidth = 1; + } else { + uvc_printk(KERN_INFO, device %s requested %u bytes +per payload.\n, video-vdev-name, bandwidth); } for (i = 0; i intf-num_altsetting; ++i) { ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Minoru stereo webcam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Laurent, I have applied your patch and here are the data: - - luvcview -s 640x480 -i 30 -d /dev/video0 uvcvideo: device Vimicro USB2.0 PC Camera requested 3072 bytes per payload. - - luvcview -s 320x240 -i 30 -d /dev/video0 uvcvideo: device Vimicro USB2.0 PC Camera requested 3072 bytes per payload. - - luvcview -s 176x144 -i 30 -d /dev/video0 uvcvideo: device Vimicro USB2.0 PC Camera requested 3072 bytes per payload. - - luvcview -s 160x120 -i 30 -d /dev/video0 uvcvideo: device Vimicro USB2.0 PC Camera requested 3072 bytes per payload. It makes no difference whether I am asking for 30 or 15fps neither - always 3072 bytes are requested. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJhjGun11XseNj94gRAqdFAKCKcWQ6tQO3ndMMYD6oAohNSdM0NQCgi6zv mG8ior07wtd6eRenWtKX2L0= =0NcE -END PGP SIGNATURE- ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] Minoru stereo webcam
Laurent and all, I just got one of those new Minoru stereo webcams. At 90 bucks from Amazon, the Minoru is several times cheaper than any alternative, and there are lots of cool things you could do with a stereo camera under Linux (see http://www.minoru3d.com/ ). The good news is that uvcvideo recognizes the stereo camera as two separate cameras (which appear as /dev/video0 and /dev/video1 in my laptop with Ubuntu 8.10). I can grab video from the left and right camera separately with no problem. I'm using the standard uvcvideo driver that comes with Ubuntu 8.10 Intrepid. The problem is that I cannot seem to be able to grab from both cameras simultaneously. If I turn on streaming on one camera, the second camera refuses to turn on streaming. In other words ioctl(fd, VIDIOC_STREAMON, type) with type = V4L2_BUF_TYPE_VIDEO_CAPTURE fails (it returns -2). dmesg says: uvcvideo: Failed to submit URB 0 (-28). Similarly, if I have luvcview running on one camera and I try to start luvcview on the other camera, I get the error message: Unable to start capture: No space left on device I suspect this is a problem with the USB bus bandwidth. The problem with luvcview occurs even if I reduce the resolution to 160x120 with luvcview -d /dev/video0 -s 160x120 Is there an easy fix? A difficult fix? Thanks, -- Yann Trace of luvcview: $ luvcview -d /dev/video0 [1] 6266 $ luvcview 0.2.4 SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: Frame format: YUYV (MJPG is not supported by device) Frame size: 640x480 Frame rate: 30 fps $ luvcview -d /dev/video1 [2] 6296 $ luvcview 0.2.4 SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video1 Stream settings: Frame format: YUYV (MJPG is not supported by device) Frame size: 640x480 Frame rate: 30 fps Unable to start capture: No space left on device Error grabbing Cleanup done. Exiting ... $ Here is the output of sudo lsusb -v for one of the cameras (the other is deleted to stay below the 40KB limit). Bus 005 Device 020: ID 0ac8:3410 Z-Star Microelectronics Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x0ac8 Z-Star Microelectronics Corp. idProduct 0x3410 bcdDevice1.00 iManufacturer 1 Vimicro Corp. iProduct2 Vimicro USB2.0 PC Camera iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 481 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 128mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 14 Video bFunctionSubClass 3 Video Interface Collection bFunctionProtocol 0 iFunction 2 Vimicro USB2.0 PC Camera Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass14 Video bInterfaceSubClass 1 Video Control bInterfaceProtocol 0 iInterface 2 Vimicro USB2.0 PC Camera VideoControl Interface Descriptor: bLength13 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdUVC 1.00 wTotalLength 79 dwClockFrequency 30.00MHz bInCollection 1 baInterfaceNr( 0) 1 VideoControl Interface Descriptor: bLength18 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Camera Sensor bAssocTerminal 0 iTerminal 0 wObjectiveFocalLengthMin 0 wObjectiveFocalLengthMax 0 wOcularFocalLength0 bControlSize 3 bmControls 0x000a Auto-Exposure Mode Exposure Time (Absolute) VideoControl Interface Descriptor: bLength11 bDescriptorType36 bDescriptorSubtype 5 (PROCESSING_UNIT) Warning: Descriptor too short bUnitID 2