Hi, all Patch definitely is not a solution. I performed a deep investigation of this problem. I tested driver on x86 and amd64 architectures with "reply" and "reset" patches and without them. As a result I found, that replying control message almost doesn't help. At some point camera doesn't acknowledge the message and goes to "broken" state. Replying in most cases returns -32 (-EPIPE) error. Sometimes it can be -75(-EOVERFLOW) error, which indicates a "bubble" situation - in my understanding, camera sends us data, which we don't request and don't expect. After -32 or -75 error we will always receive -110 (ETIMEDOUT). Hardware not understand us, the only way is to reset camera, either by calling usb_reset_device() or by unplugging the cord.
I performed this investigation, using small program, that changes camera controls in loop with random values. The -32 error code usually is returned after I try to change any control immediately after gamma, white balance or exposure controls. Camera need more time to physically apply this controls to hardware. So, I think, that we send controls to quickly. Yes, camera must acknowledge control packet only after it applied it to hardware. But who knows does it do so or not. The solution may be in a delay between to calls of usb_control_msg(). I'm performing this tests now and almost ready to post the patch. Martin and Laurent, I need your opinion about this. Again and again, sorry for my English. I really hope, that this message is readable at least partly Regards, Evgeny _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
