RPi pipeline handler expects V4L2_PIX_FMT_SRGGB10P

[kbingham]

Creating an issue here to prevent thread pollution over at
raspberrypi/linux#3220

From @6by9

Is there some magic required to run qcam?
I've compiled your kbingham/rpi branch, it runs, select imx219 0-0010, hit OK, and it crashes

qt5ct: using qt5ct plugin
[0:09:55.710525042] INFO Camera camera_manager.cpp:94 libcamera v0.0.0+708-893f2dde
Using camera imx219 0-0010
[0:10:12.339871854] INFO Camera camera.cpp:666 configuring streams: (0) 320x240-0x56595559
[0:10:12.340219534]  ERR RPI raspberrypi.cpp:188 Failed to set format on Video device: 1920x1080-0x41414270
Failed to configure camera
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 705, resource id: 20973393, major code: 40 (TranslateCoords), minor code: 0

/dev/video0 is set to 1920x1080 raw10 BGGR

Gstreamer seems not to be hitting issues when doing things like video transcode (filesrc ! matroskademux ! h264parse ! v4l2h264dec ! v4l2h264enc). That may be because it intercepts ctrl-c and does some cleanup.
v4l2convert doesn't support raw10, and throws a minor grump with raw8 from ov5647. I'm putting that down to a Gstreamer quirk rather than anything else.

[kbingham]

From : @andrey-konovalov

Is there some magic required to run qcam?
I've compiled your kbingham/rpi branch, it runs, select imx219 0-0010, hit OK, and it crashes

[0:10:12.340219534]  ERR RPI raspberrypi.cpp:188 Failed to set format on Video device: 1920x1080-0x41414270

...

/dev/video0 is set to 1920x1080 raw10 BGGR

The 0x41414270 (in the error message above) is indeed V4L2_PIX_FMT_SBGGR10P (what your /dev/video0 is using). But the pipeline handler (raspberrypi.cpp) tries to set V4L2_PIX_FMT_SRGGB10P (the hardcoded value), and returns the error ("Failed to set format on Video device...") if the resulting format is different from RGGB.

The quick hack I've used was to change the V4L2_PIX_FMT_SRGGB10P to V4L2_PIX_FMT_SBGGR10P in src/libcamera/pipeline/raspberrypi.cpp. (The proper fix would be to make the pipeline handler more flexible WRT sensor pixel format)

[6by9]

Thanks @andrey-konovalov - that was exactly it.

IIRC It's not handled yet in the imx219 driver but HFLIP and VFLIP normally change the Bayer order on this sensor as they reverse the direction the array is readout. Unicam does the "wrong" thing at the moment by caching the values the sensor driver enumerates at boot, but any hardcoding of the Bayer format sounds like bad news. (I know it's still early days for this pipeline).

[kbingham]

Aha - ok - that explains the discrepency - I've just checked my kernel tree, and I seem to be carrying a patch from @6by9 "Fixup imx219: Correct flips/mirror to native orientation. Adds test pattern controls" which now I look into it - does indeed change the pixel formats:

• fmt->format.code = MEDIA_BUS_FMT_SBGGR10_1X10;

• fmt->format.code = MEDIA_BUS_FMT_SRGGB10_1X10;

sorry for the confusion - I must have picked that up during rebases on top of earlier branches of the imx219. But it does indeed show that I need to make the pipeline more dynamic already :-)

[kbingham]

7aca293 should resolve this issue. I've rebased and updated my kbingham/rpi branch to include this fix.

[6by9]

Hmm, test pattern control should have been merged. It's quite possible that I've messed up in my rebasing :-( Guess I'd better check

[kbingham]

The kbingham/rpi branch now resolves this issue through commit titled
"libcamera: pipeline: raspberrypi: Remove hardcoded sensor format"

(I'll not bother with a sha1 reference as my branch isn't stable yet)