Hi David, On Sat, Sep 14, 2024 at 01:01:25AM +0200, David Given wrote: > After learning the difference between GUID text and memory > representation, I have hacked support into the kernel. And it doesn't > work. > > The kernel tracing says this: > > mplayer says this: > > ---snip--- > name: Video 4 Linux 2 input > author: Martin Olschewski <olschewski@xxxxxxxxxxxxxxxx> > comment: first try, more to come ;-) > v4l2: your device driver does not support VIDIOC_G_STD ioctl, VIDIOC_G_PARM was > used instead. > Selected device: IR VIDEO: IR Camera > Capabilities: video capture streaming > supported norms: > inputs: 0 = Camera 1; > Current input: 0 > Current format: RGB565 > v4l2: ioctl set format failed: Input/output error > v4l2: ioctl set mute failed: Invalid argument > v4l2: 0 frames successfully processed, 0 frames dropped. > ---snip--- > > mplayer says this: > > ---snip--- > [17267.675757] usb 3-5.4.3: UVC non compliance - GET_DEF(PROBE) not > supported. Enabling workaround. > [17460.849025] uvcvideo 3-5.4.3:1.1: Failed to query (130) UVC probe > control : -32 (exp. 26). > (this last line appears when mplayer runs) Ouch :-( > ---snip--- > > v4l2-compliance's report on the format ioctls says this (the entire > thing for both devices is on pastebin as it's big: > https://pastebin.com/RAzpkigp) > > ---snip--- > Format ioctls (Input 0): > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > fail: v4l2-test-formats.cpp(1442): ret && node->has_frmintervals > test VIDIOC_G/S_PARM: FAIL > test VIDIOC_G_FBUF: OK (Not Supported) > test VIDIOC_G_FMT: OK > fail: v4l2-test-formats.cpp(767): Video Capture is valid, but no > TRY_FMT was implemented > test VIDIOC_TRY_FMT: FAIL > fail: v4l2-test-formats.cpp(473): expected EINVAL, but got 5 whe > n getting format for buftype 1 > test VIDIOC_S_FMT: FAIL > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > test Cropping: OK (Not Supported) > test Composing: OK (Not Supported) > fail: v4l2-test-formats.cpp(1853): doioctl(node, VIDIOC_S_FMT, & > fmt) > fail: v4l2-test-formats.cpp(2001): testBasicScaling(node, fmt) > test Scaling: FAIL > ---snip--- > > I'm feeling like this is a very ill camera. However, capturing does Lots of UVC cameras are very ill, as vendors typically test their devices with windows only :-S > work on Windows. I see there is support for UVC device quirks > (https://elixir.bootlin.com/linux/v6.10.10/source/drivers/media/usb/uvc/uvcvideo.h#L63). > Any suggestions of anything which might work? I tried a few things > randomly and nothing seemed to make a difference. 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. > On Thu, 12 Sept 2024 at 12:52, Ricardo Ribalda <ribalda@xxxxxxxxxxxx> wrote: > > > > Hi David > > > > > > On Wed, 11 Sept 2024 at 21:58, David Given <dg@xxxxxxxxxxx> wrote: > > > > > > Hello, > > > > > > I've just received a review sample thermal camera which doesn't work > > > with Linux uvcvideo. It's reporting itself as providing a D3DFMT GUID: > > > > > > ---snip--- > > > VideoStreaming Interface Descriptor: > > > bLength 27 > > > bDescriptorType 36 > > > bDescriptorSubtype 4 (FORMAT_UNCOMPRESSED) > > > bFormatIndex 1 > > > bNumFrameDescriptors 1 > > > guidFormat > > > {e436eb7b-524f-11ce-9f53-0020af0ba770} > > > bBitsPerPixel 16 > > > bDefaultFrameIndex 1 > > > bAspectRatioX 0 > > > bAspectRatioY 0 > > > bmInterlaceFlags 0x00 > > > Interlaced stream or variable: No > > > Fields per frame: 2 fields > > > Field 1 first: No > > > Field pattern: Field 1 only > > > bCopyProtect 0 > > > ---snip--- > > > > > > This corresponds to D3DFMT_R5G6B5 or MEDIASUBTYPE_RGB565, based on the > > > reference here: https://gix.github.io/media-types/#ID0EC2AI However, > > > the UVC driver is expecting RGB565 to be using the 4cc RGBP GUID > > > 52474250-0000-1000-8000-00aa00389b71. This is very nearly the same as > > > the alternative GUID described on the document above, > > > 00000017-0000-0010-8000-00AA00389B71, which uses an index rather than > > > a 4cc. > > > > > > I haven't been able to find any references as to what GUIDs are > > > supported for guidFormat. > > > > The uvc spec only defines GUIDs for YUY2, NV12, M420 and I420. > > > > It would have been nice that the vendor had used the same GUID as > > TomTom (Check 507910799160e85eac5e7729e0d2f1ba26f6a8cf) > > but apparently it is not required to be like this. > > > > > > Why dont you try adding a new mapping to include/linux/usb/uvc.h and > > drivers/media/common/uvc.c ? Similar to what Marek did here: > > 015d44c2b700ba9639dd29672ba362796cc0be54 > > > > I believe that if a camera does not use TomToms GUID and the new GUI, > > everything would work... > > > > Regards > > > > > (a) Is the camera wrong? > > > (b) Is the kernel wrong? > > > (c) Am I looking at the wrong document? > > > > > > The easy fix is to patch the uvcvideo driver to support the e436... > > > GUID, but that doesn't seem a great idea. Any suggestions? -- Regards, Laurent Pinchart
