Re: No uvc video support for D3DFMT video GUIDs?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux