On 07/08/2012 03:18 AM, Alan Stern wrote: > Apparently the behavior before commit e1620d5 was that the webcam > didn't get suspended, and after the commit it did. Unfortunately > the usbmon traces do not explain this difference; all they show is > when/whether a suspend took place. > > For example, the prelog.9975961.out trace shows that the webcam wasn't > suspended before the trace began, and the postlog.e1620d5.out trace > shows that it was (although when the webcam was resumed, it did work > okay -- this was one of the times it didn't crash during the resume).
Let me clarify: the webcam did *not* work okay during the session represented by postlog.e1620d5.out; it turned back on, but only returned a garbled video image. So even here, it really needs the reset-resume quirk. > Eric, are your kernel-hacking skills up to debugging this? I can tell > you where to look and what to look for. I'm not a kernel hacker -- almost all my development/coding experience is at the application/UI level. But I can read and modify C, and I can compile a kernel. :-) So if you don't mind a little hand-holding, I am happy to help however I can. Eric -- 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
