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.
