Supported formats updates

[xzhangxa]

• Revert the modification of existing format definition, add new items in vi5_formats with dedicated MEDIA_BUS_FMT_XXX (VI code uses it as key to search);
• Correct color sensor V4L2 format to UYVY that the real data from camera/FW always is;
• Update rs_viewer for UYVY change.

Color UYVY change is for JIRA https://rsjira.intel.com/browse/DSO-18099.

This is part of effort of cleanup.

Signed-off-by: Xin Zhang xin.x.zhang@intel.com

[xzhangxa]

Copy from email:

For the byte order of UYVY, Y8I, Y12I, could you check with HW/FW engineer or document again? Yesterday in the meeting you mentioned the MIPI CSI spec and V4L2 Y12I/Y8I definitions, but it’s still not the real data byte order from HW. Actually from the current behavior of the stream data, I suspect the color stream data is sent by HW as YUYV, and Y12I is right first left second.

For example this is the formats definition for our color stream, the first highlight item is set for MMIO DMA descriptor 8 bits, but we don’t find NVIDIA’s HW spec for it so we can only test and guess. The below works fine for UYVY at user space’s perceptive, but you can see if we set the first highlight to YUYV the stream will be UYVY, if set it to UYVY the stream will be YUYV… This also mismatches with NVIDIA’s own YUYV/UYVY definitions that they match the V4L2 format in order.

_TEGRA_VIDEO_FORMAT(YUV422, 16, SGRBG16_1X16, 2, 1, T_Y8_U8__Y8_V8, YUV4228, UYVY, "YUV 4:2:2");

The format and byte order may be affected by many factors: HW, MIPI format setting, how FW handles the custom 0x31/32 format. Though we can ignore all the mess and just make color and Y8I match with the user known V4L2 format no matter what the item name is (we don’t have DMA HW spec, anyway), there’s still one issue: Y12I can only be right first as we cannot change the second byte’s bit order and I suspect Y12I stream data is really right first.

[dmipx]

This change broke librealsense compatibility. I will try to integrate changes step-by-step.

[Nir-Az]

Thanks Xin, Our future development should be based on 'Jetpack-5.0.2' branch. Our plan is to override master with Jetpack-5.0.2 once it will be validated.