<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   ***: IanWizard has quit IRC (Ping timeout: 244 seconds)
   venkat_330: Hi all in my system i am trying to use 3 cameras 1 for image capture and 2 others for video capture. We notice that out of 3 available cameras only 2 works. While tailing kern log noticed (VIDIOC_STREAMON: No space left on device). I was randomly searching about this error and it pointed modprobe quirks=128 might help. Yes it did work on my system all 3 cameras work. I just want to understand what would be the after effects in system functionalities. Wou
   ***: Tex_Nick has left "In Linux, We Trust"
   pinchartl: <u>venkat_330</u>: the issue is that some UVC devices don't report their required USB bandwidth correctly. they instead tell the host that they need to maximum bandwidth, resulting in USB bandwidth starvation due to overallocated bandwidth
   <br> that's where the "No space left on device" error comes from
   <br> as a work around quirks=128 will compute an estimate of the needed bandwidth based on the frame size instead of using the value reported by the device
   venkat_330: <u>pinchartl</u>: If I use this quirk will it harm my system performence??
   pinchartl: the only possible resulting issue would be that the bandwidth could be underestimated, the device then would simply not work properly as USB packets would be dropped and part of the image would be lost
   <br> that's a local issue only, there should be no adverse effects to other devices or to the system in general
   venkat_330: <u>pinchartl</u>: That is fien for me.. I am operation video devices at 6 fps.. think this should not bother a lot
   pinchartl: the frame rate unfortunately doesn't matter
   <br> at lower frame rates devices usually send frames at the same speed they would for higher frame rates, and simply wait between frames
   <br> the peak bandwidth is thus the same
   <br> the reason for that is that transmitting a frame over a longer period of time would require buffering the whole frame on the device size
   <br> and memory being expensive, that's not possible with most devices
   venkat_330: <u>pinchartl</u>: Thanks for the pointers will use this fix in my system.Hope there should not be any failures
   pinchartl: you're welcome
   <br> could you have a look at http://ideasonboard.org/uvc/faq/#faq7 and tell me if it's clear enough ?
   venkat_330: <u>pinchartl</u>: You nailed it. Thanks
   pinchartl: you're welcome
   courrier: <u>pinchartl</u>: I do have the same issue than venkat_330 with a -28 error for 2 simultaneous HD cams, even plugged on different buses, capturing in MJPEG, and 1 of them is even connected to an USB3 controller, not sure why I still get -28
   <br> Is there another hope for connecting two cameras?
   <br> (UVC_QUIRK_FIX_BANDWIDTH does not help)
   pinchartl: it should just work when the cameras behave properly
   <br> but it looks like yours don't
   <br> can you send me the 'lsusb -v' output for your cameras ?
   <br> preferably running as root
   courrier: <u>pinchartl</u>: http://paste.debian.net/432487 (Logitech, Inc. HD Webcam C910) and http://paste.debian.net/432488 (Microsoft Corp. LifeCam HD-5000)
   <br> I must be afk for a while but be back soon
   <br> thanks by advance for your help :)
   pinchartl: <u>courrier</u>: nothing wrong so far
   <br> <u>courrier</u>: http://ideasonboard.org/uvc/faq/#faq7
   <br> more specifically, "You can find how how much bandwidth the device requests and which alternate setting the driver selects by setting the uvcvideo module trace parameter to 0x400. The driver will print bandwidth-related information to the kernel log."
   <br> could you find that out ?
   <br> (please read the rest of the document too)
   courrier: Mmmmmh ok that's really weird, today both cameras work at the same time haha...
   <br> quirks=640 should do the job right?
   <br> cause I don't see the bandwith in the output
   <br> ha mmmh, "to the kernel  log"
   pinchartl: it's quirks=128, not 640
   <br> and it only affects uncompressed video streams
   <br> it doesn't help with MJPEG
   courrier: <u>pinchartl</u>: I wanted to print the bandwidth, that's 1024+128 then
   <br> does using MJPEG actually reduces the bandwidth however?
   pinchartl: it should, yes
   <br> but again the device might just keep asking for maximum bandwidth even if it could work with less
   ***: smartin has quit IRC (*.net *.split)
   <br> r0kc4t_ has quit IRC (*.net *.split)
   <br> crope has quit IRC (*.net *.split)
   ndufresne: <u>pinchartl</u>: hello, did that patch was forgotten ? https://patchwork.linuxtv.org/patch/32546/
   pinchartl: <u>ndufresne</u>: it got buried in my inbox
   <br> I've just replied to the e-mail
   ***: Tex_Nick has left "In Linux, We Trust"
   <br> benjiG has left
   mike_: hi all
   Guest19331: can someone help regarding how to patch a .patch after building latest v4l
   <br> need to patch this https://patchwork.linuxtv.org/patch/32786/
   <br> or redirect me to a documentation/link on how to do it
   <br> thanks in advance
   ***: UukGoblin has quit IRC (*.net *.split)
   <br> koike has quit IRC (*.net *.split)
   Guest19331: anyone?
   APic: sx
   <br> Fail, sorry.
   ***: Marex has quit IRC (*.net *.split)
   <br> APic has quit IRC (Ping timeout: 260 seconds)