On 07.07.2012 13:38, Eric Ding wrote: > On 07/07/2012 06:09 PM, Oleksij Rempel wrote: >> On 07.07.2012 11:20, Eric Ding wrote: >>> On 07/06/2012 11:47 PM, Alan Stern wrote: >>>> On Fri, 6 Jul 2012, Alan Cox wrote: >>>> >>>>>> Yes, but we still need to know the reason why. Neither Rafael nor I >>>>>> has been able to figure out why that commit messed things up. >>>>> >>>>> Was the driver doing any dynamic autosuspend at all until that point ? >>>> >>>> I don't know... but whatever it was doing before the commit, it should >>>> be doing the same thing afterward. >>> >>> I thought that getting some comparative usbmon logs might help, but I'm >>> not equipped to parse them. To generate these logs, I ran guvcview once >>> after plugging in the webcam, then did the following upon quiting >>> guvcview: start listening via usbmon, sleep for four seconds, start >>> guvcview again and stop listening via usbmon after four seconds. >>> >>> I did this both at commit e1620d5 (the commit which triggered this >>> issue) and once at commit 9975961 (one commit prior). Going through >>> these motions also confirmed that the problem is readily reproducible >>> the second time I start guvcview at e1620d5, but not at 9975961. I've >>> attached both logs in case they're helpful. >> >> In both logs you send the cam start to stream video. Major difference is >> that, after suspend/resume it need more time (about 10 seconds) to start >> stream. Is it correct? > > My tests didn't continue a full 10 seconds after I restarted the webcam, > so I'm not sure I follow your question. In the second case (with > e1620d5), the camera never returns a "normal" video image -- instead, it > gets a garbled video image of horizontal stripes, which change with what > the camera lens is seeing, but are obviously not the correct image. > > The stream does take longer to come up on the second time than the > first, though, during which I see the following error message in > guvcview 1-3 times: > > Could not grab image (select timeout): Resource temporarily unavailable > > Sorry if I'm not answering your question helpfully! > > Eric >
Ok, i guess i know your problem but i doubt it will be completely fixed by changing powermanagement behavior. Two logitech cams i tested is really easy to confuse/brake/freeze. Just turn off the stream before it will send first frame. It looks like it take longer to boot buildin controller or image processor. On second (hot) start it take less time. If the cam was suspended it need this boot time again. The problem, even if we do hot start and turn of stream before first frame, like some apps did, the cam will brake again. By disabling auto suspend, we will reduce probability to brake it, but not fix it. Some times i have the splitimage issue too, but i can't 100% reproduce it. -- Regards, Oleksij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
