Hi David, On Sat, Sep 14, 2024 at 12:19:39PM +0200, David Given wrote: > Solved. https://imgur.com/a/vGJ0Y4a > > Turns out the necessary quirk was UVC_QUIRK_PROBE_MINMAX, and then > v4l2-compliance goes green and video comes out. It's even the right > colour. I'm glad you managed to fix your issue. > I will polish this up into a patch and send it. Is the list the right > place or should this go to a specific maintainer? The linux-media mailing list is the right place. Please CC me as well. > On Sat, 14 Sept 2024 at 02:23, David Given <dg@xxxxxxxxxxx> wrote: > > > > D'oh! The kernel logs which say this: > > > > ---snip--- > > [23824.213720] uvcvideo 3-5.4.3:1.1: Failed to query (130) UVC probe control : - > > 32 (exp. 26). > > ---snip--- > > > > ...show what's going on; the device is reporting an incorrect control > > packet size. It's probably completely ignoring the incoming packet > > size and assuming they'll always be 32 bytes, which is wrong. -32 is the -EPIPE error code. According to Documentation/driver-api/usb/error-codes.rst, this means the endpoint has stalled. The camera's firmware "just" doesn't implement support for this request, and possibly crashed. Apparently the windows driver doesn't call GET_MIN and GET_MAX on the video probe control, and so lots of webcams don't implement it. > > On Sat, 14 Sept 2024 at 02:13, David Given wrote: > > > On Sat, 14 Sept 2024 at 01:40, Laurent Pinchart wrote: > > > [...] > > > > UVC_QUIRK_PROBE_DEF may help. Please check if it results in any change > > > > in the kernel log messages, not just if you can capture frames from the > > > > camera, as sometimes multiple quirks may be needed. > > > > > > Thanks for the suggestion --- I tried it, and the kernel messages did > > > indeed look a bit better, but I suspect only because it's not doing > > > the GET_DEF anymore so isn't reporting it as an error. > > > > > > ---snip--- > > > [23584.241771] usb 3-5.4.3: Found UVC 1.00 device IR VIDEO (1fc9:009b) > > > [23584.241775] usb 3-5.4.3: Forcing device quirks to 0x100 by module parameter f > > > or testing purpose. > > > [23584.241777] usb 3-5.4.3: Please report required quirks to the linux-media mai > > > ling list. > > > [23584.246791] usbcore: registered new interface driver uvcvideo > > > ---snip--- > > > > > > Still doesn't work, mind. > > > > > > My gut feeling based on looking at the compliance logs and no > > > experience with how things actually work is that the format selection > > > commands are a mess, maybe because they're not expecting the client to > > > actually try to select or enumerate the formats but instead just > > > process the frames the device gives? This line looks suspicious: > > > > > > ---snip--- > > > test VIDIOC_TRY_FMT: FAIL > > > fail: v4l2-test-formats.cpp(473): expected EINVAL, but got 5 whe > > > n getting format for buftype 1 > > > ---snip--- > > > > > > 5 is EIO, so if they're failing the request incorrectly that will > > > confuse all clients which consider EIO to be a fatal error. It should > > > be easily quirkable; I'll give it a try. -- Regards, Laurent Pinchart
