Re: [Linux-uvc-devel] Minoru stereo webcam: Auto Control deactivation

2009-03-24 Thread Laurent Pinchart
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

2009-03-19 Thread julien quelen
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

2009-03-02 Thread Laurent Pinchart
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

2009-03-01 Thread Laurent Pinchart
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

2009-03-01 Thread Yann LeCun
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

2009-02-16 Thread Jan Ciger
-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

2009-02-16 Thread Jan Ciger
-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

2009-02-16 Thread Jan Ciger
-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

2009-02-16 Thread Laurent Pinchart
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

2009-02-16 Thread Yann LeCun
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

2009-02-16 Thread Jan Ciger
-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

2009-02-16 Thread Jan Ciger
-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

2009-02-16 Thread Yann LeCun
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

2009-02-16 Thread Yann LeCun
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

2009-02-15 Thread Laurent Pinchart
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

2009-02-15 Thread Jan Ciger
-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

2009-02-15 Thread Laurent Pinchart
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

2009-02-14 Thread Laurent Pinchart
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

2009-02-14 Thread Jan Ciger
-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

2009-02-05 Thread Laurent Pinchart
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

2009-02-03 Thread Jan Ciger
-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

2009-02-03 Thread Simone Freddio

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

2009-02-03 Thread Jan Ciger
-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

2009-02-02 Thread Jan Ciger
-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

2009-02-02 Thread Simone Freddio
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

2009-02-02 Thread Laurent Pinchart
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

2009-02-01 Thread Jan Ciger
-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

2009-02-01 Thread Laurent Pinchart
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

2009-02-01 Thread Jan Ciger
-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

2009-01-31 Thread Yann LeCun
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