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 will polish this up into a patch and send it. Is the list the right place or should this go to a specific maintainer? Thanks! 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. > > On Sat, 14 Sept 2024 at 02:13, David Given <dg@xxxxxxxxxxx> wrote: > > > > On Sat, 14 Sept 2024 at 01:40, Laurent Pinchart > > <laurent.pinchart@xxxxxxxxxxxxxxxx> 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.
