On 07/07/2012 09:11 PM, Oleksij Rempel wrote: > 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. > > 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. So does your description of the problem explain why commit e1620d5 causes this problem to happen 100% of the time on the second start, even though I cannot reproduce this problem at all before that commit? Isn't that the mystery that still remains unsolved? Do the usbmon logs not answer that question? Going back also to the patch I submitted, it seems (at least in my testing) that USB_QUIRK_RESET_RESUME does work around this issue consistently, at least for my webcam. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
