On 07/09/2012 08:38 AM, Alan Stern wrote: > On Sun, 8 Jul 2012, Laurent Pinchart wrote: > >>> this quirks also affect snd_usb_audio module. If for some reasons >>> uvcvideo is not loaded, snd_usb_audio will fail - i mean haw mysterious >>> sound problems. >> >> Good point. If we load the uvcvideo driver while the audio function is in use, >> I doubt resetting the device will lead to a good user experience. One could >> argue whether this should happen in the first place though, as modules should >> be auto-loaded. Could there be a race between audio and video probe, leading >> to audio probe failure because we reset the device in the middle of the probe >> sequence ? > > Even if there's no race and uvcvideo never gets loaded, there still > could be a problem. The device could get suspended while waiting for > the snd-usb-audio module to load. Then when the audio driver is > probed, it could be looking at a webcam that has already crashed > because the RESET_RESUME quirk was never set. > > An alternative would be to modify the usb_detect_quirks() routine > directly -- have it set RESET_RESUME whenever it sees a Logitech > webcam. The difficulty there is how to recognize which devices are > webcams. Look for a video interface? > > Any suggestions? I may be misreading the code, but it looks like uvc_driver.c just looks for the USB_CLASS_VIDEO interface class. In saying this, though, it appears that several Logitech (and other) webcams don't actually have their interface class set to VENDOR_SPEC instead because they don't announce themselves as UVC devices. So it looks like you'd have to both look for USB_CLASS_VIDEO and check uvc_ids[] too... which becomes somewhat hairy, since I assume you don't realy want usb_detect_quirks() to reference UVC-specific structs... which brings us back to the original laundry list approach of naming several affected webcams explicitly, no? 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
