[UPDATED, SOLVED] Why "cheap" Chinese HDMI-to-CSI2 adapters (e.g.18810-1 C779) doesn't provide I2S sound

[idcidc]

Hi, All!
There are a lot of posts here about problems with I2S on cheap Chinese HDMI-to-CSI2 modules, while more expensive modules by Auvidea with the same TC358743 IC by Toshiba works fine and is supported by kernel drivers and overlays (thanks to Community and personally to 6by9 user).
I've bought this "cheap" board, faced problem with I2S and started my investigation of this problem. Here I present some materials that explain why there is no way to get sound from "cheap" board without it hardware modification.
In brief: APLL circuit is not properly routed on PCB.

Also I'm now working on "hardware patch" to add the possibility to work with I2S to mentioned cheap boards.

Hardware patch is done, it implements mentioned schematics which is absent on original PCB and is mounted using a drop of melt glue to the adapter's PCB. Now sound via I2S works good as with original B100 board by Auvidea using yavta as mentioned here: viewtopic.php?p=1324281#p1324281.
Patch PCB itself:

"Upgraded" cheap Chinese adapter:

[idcidc]

Another problem with these cheap adapters appears to exist. While running all the steps from viewtopic.php?p=1324281#p1324281 with original B100 adapter by Auvidea I obtain perfect picture (yavta -> mmal), sound via I2S is present, as expected.

Video source is HXR-NX5U camcorder by Sony, running at 720p, 60fps. Color bars & test tone generator is enabled.

Logs of "normal" execution with original B100:

Code: Select all

CTA-861 Header
  IT Formats Underscanned: yes
  Audio:                   yes
  YCbCr 4:4:4:             no
  YCbCr 4:2:2:             no

HDMI Vendor-Specific Data Block
  Physical Address:        3.0.0.0
  YCbCr 4:4:4 Deep Color:  no
  30-bit:                  no
  36-bit:                  no
  48-bit:                  no

CTA-861 Video Capability Descriptor
  RGB Quantization Range:  yes
  YCC Quantization Range:  no
  PT:                      Supports both over- and underscan
  IT:                      Supports both over- and underscan
  CE:                      Supports both over- and underscan
Device /dev/video0 opened.
Device `unicam' on `platform:unicam 3f801000.csi1' (driver 'unicam') is a video capture (without mplanes) device.
stride is 0
stride is now 1280
Video format set: UYVY (59565955) 1280x720 (stride 2560) field none buffer size 1843200
QUERY_DV_TIMINGS returned 1280x720 pixclk 74250000
Framerate is 50
Video format: UYVY (59565955) 1280x720 (stride 2560) field none buffer size 1843200
vc.ril.isp:in:0(UYVY)(0x11dcd20)type: video, fourcc: UYVY bitrate: 0, framed: 0 extra data: 0, (nil) width: 1280, height: 720, (0,0,1280,720) pixel aspect ratio: 0/0, frame rate: 0/0
buffers num: 6(opt 1, min 1), size: 1843200(opt 1843200, min: 1843200), align: 0
Created pool of length 6, size 0
Create pool of 3 buffers of size 0 for render
Create pool of 3 buffers of size 1382400 for encode/render
6 buffers requested, V4L2 returned 6 bufs.
length: 1843200 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x7314d000.
Importing DMABUF 6 into VCSM...
...done. vcsm_handle 77824
Exported buffer 0 to dmabuf 6, vcsm handle 77824
Linking V4L2 buffer index 0 ptr 0x11e30b8 to MMAL header 0x11e10c0. mmal->data 0xC0000002
length: 1843200 offset: 1843200 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x72f8b000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 81920
Exported buffer 1 to dmabuf 8, vcsm handle 81920
Linking V4L2 buffer index 1 ptr 0x11e3128 to MMAL header 0x11e1298. mmal->data 0xC0000003
length: 1843200 offset: 3686400 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x72dc9000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 86016
Exported buffer 2 to dmabuf 9, vcsm handle 86016
Linking V4L2 buffer index 2 ptr 0x11e3198 to MMAL header 0x11e1470. mmal->data 0xC0000004
length: 1843200 offset: 5529600 timestamp type/source: mono/EoF
Buffer 3/0 mapped at address 0x72c07000.
Importing DMABUF 10 into VCSM...
...done. vcsm_handle 90112
Exported buffer 3 to dmabuf 10, vcsm handle 90112
Linking V4L2 buffer index 3 ptr 0x11e3208 to MMAL header 0x11e1648. mmal->data 0xC0000005
length: 1843200 offset: 7372800 timestamp type/source: mono/EoF
Buffer 4/0 mapped at address 0x72a45000.
Importing DMABUF 11 into VCSM...
...done. vcsm_handle 94208
Exported buffer 4 to dmabuf 11, vcsm handle 94208
Linking V4L2 buffer index 4 ptr 0x11e3278 to MMAL header 0x11e1820. mmal->data 0xC0000006
length: 1843200 offset: 9216000 timestamp type/source: mono/EoF
Buffer 5/0 mapped at address 0x72883000.
Importing DMABUF 12 into VCSM...
...done. vcsm_handle 98304
Exported buffer 5 to dmabuf 12, vcsm handle 98304
Linking V4L2 buffer index 5 ptr 0x11e32e8 to MMAL header 0x11e19f8. mmal->data 0xC0000007
0 (0) [-] none 0 1843200 B 202.913365 202.914643 -16949.153 fps ts mono/EoF
1 (1) [-] none 1 1843200 B 202.914655 202.934642 775.194 fps ts mono/EoF
2 (2) [-] none 2 1843200 B 202.934655 202.954682 50.000 fps ts mono/EoF
3 (3) [-] none 3 1843200 B 202.954661 202.974640 49.985 fps ts mono/EoF
4 (4) [-] none 4 1843200 B 202.974656 202.994640 50.013 fps ts mono/EoF
5 (5) [-] none 5 1843200 B 202.994655 203.014639 50.003 fps ts mono/EoF
6 (0) [-] none 6 1843200 B 203.014656 203.034637 49.998 fps ts mono/EoF
7 (1) [-] none 7 1843200 B 203.034656 203.054671 50.000 fps ts mono/EoF
8 (2) [-] none 8 1843200 B 203.054656 203.074640 50.000 fps ts mono/EoF
9 (3) [-] none 9 1843200 B 203.074656 203.094640 50.000 fps ts mono/EoF

================== < OUTPUT OMITTED >=========================

9999 (3) [-] none 9999 1843200 B 405.794913 405.814925 50.000 fps ts mono/EoF
Captured 10000 frames in 202.901501 seconds (49.284998 fps, 6171126.427712 B/s).
Total number of frames dropped 3
Releasing vcsm handle 77824
Closing dma_buf 6
Releasing vcsm handle 81920
Closing dma_buf 8
Releasing vcsm handle 86016
Closing dma_buf 9
Releasing vcsm handle 90112
Closing dma_buf 10
Releasing vcsm handle 94208
Closing dma_buf 11
Releasing vcsm handle 98304
Closing dma_buf 12
6 buffers released.

Output to STDERR is empty.

When disconnect B100 and connect "cheap board" (on powered-down PI, of course ) I got strange random behavior:
1.Sometimes it shows partial video (top-left corner, 640x480), few frames and then freezes.
2.Sometimes it shows "garbage" and also freezes.
Logs of "abnormal" execution:

Code: Select all

CTA-861 Header
  IT Formats Underscanned: yes
  Audio:                   yes
  YCbCr 4:4:4:             no
  YCbCr 4:2:2:             no

HDMI Vendor-Specific Data Block
  Physical Address:        3.0.0.0
  YCbCr 4:4:4 Deep Color:  no
  30-bit:                  no
  36-bit:                  no
  48-bit:                  no

CTA-861 Video Capability Descriptor
  RGB Quantization Range:  yes
  YCC Quantization Range:  no
  PT:                      Supports both over- and underscan
  IT:                      Supports both over- and underscan
  CE:                      Supports both over- and underscan
Device /dev/video0 opened.
Device `unicam' on `platform:unicam 3f801000.csi1' (driver 'unicam') is a video capture (without mplanes) device.
stride is 0
stride is now 1280
Video format set: UYVY (59565955) 640x480 (stride 1280) field none buffer size 614400
Video format: UYVY (59565955) 640x480 (stride 1280) field none buffer size 614400
Unable to get frame rate: Inappropriate ioctl for device (25).
vc.ril.isp:in:0(UYVY)(0x6e1d20)type: video, fourcc: UYVY bitrate: 0, framed: 0 extra data: 0, (nil) width: 640, height: 480, (0,0,640,480) pixel aspect ratio: 0/0, frame rate: 0/0
buffers num: 6(opt 1, min 1), size: 614400(opt 614400, min: 614400), align: 0
Created pool of length 6, size 0
Create pool of 3 buffers of size 0 for render
Create pool of 3 buffers of size 460800 for encode/render
6 buffers requested, V4L2 returned 6 bufs.
length: 614400 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x738bf000.
Importing DMABUF 6 into VCSM...
...done. vcsm_handle 28672
Exported buffer 0 to dmabuf 6, vcsm handle 28672
Linking V4L2 buffer index 0 ptr 0x6e80b8 to MMAL header 0x6e60c0. mmal->data 0xC0000002
length: 614400 offset: 614400 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x73829000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 32768
Exported buffer 1 to dmabuf 8, vcsm handle 32768
Linking V4L2 buffer index 1 ptr 0x6e8128 to MMAL header 0x6e6298. mmal->data 0xC0000003
length: 614400 offset: 1228800 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x73793000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 36864
Exported buffer 2 to dmabuf 9, vcsm handle 36864
Linking V4L2 buffer index 2 ptr 0x6e8198 to MMAL header 0x6e6470. mmal->data 0xC0000004
length: 614400 offset: 1843200 timestamp type/source: mono/EoF
Buffer 3/0 mapped at address 0x736fd000.
Importing DMABUF 10 into VCSM...
...done. vcsm_handle 40960
Exported buffer 3 to dmabuf 10, vcsm handle 40960
Linking V4L2 buffer index 3 ptr 0x6e8208 to MMAL header 0x6e6648. mmal->data 0xC0000005
length: 614400 offset: 2457600 timestamp type/source: mono/EoF
Buffer 4/0 mapped at address 0x73667000.
Importing DMABUF 11 into VCSM...
...done. vcsm_handle 45056
Exported buffer 4 to dmabuf 11, vcsm handle 45056
Linking V4L2 buffer index 4 ptr 0x6e8278 to MMAL header 0x6e6820. mmal->data 0xC0000006
length: 614400 offset: 3072000 timestamp type/source: mono/EoF
Buffer 5/0 mapped at address 0x735d1000.
Importing DMABUF 12 into VCSM...
...done. vcsm_handle 49152
Exported buffer 5 to dmabuf 12, vcsm handle 49152
Linking V4L2 buffer index 5 ptr 0x6e82e8 to MMAL header 0x6e69f8. mmal->data 0xC0000007
0 (0) [-] none 0 614400 B 138.427036 145.683790 -16666.667 fps ts mono/EoF
1 (1) [-] none 1 614400 B 145.683782 145.703771 0.138 fps ts mono/EoF
DROPPED FRAME - 0 and 7256746, delta 7256746
2 (2) [-] none 2 614400 B 145.703782 145.723787 50.000 fps ts mono/EoF
3 (3) [-] none 3 614400 B 145.723782 145.743767 50.000 fps ts mono/EoF
4 (4) [-] none 4 614400 B 145.743783 145.763800 49.998 fps ts mono/EoF
5 (5) [-] none 5 614400 B 145.763783 145.783767 50.000 fps ts mono/EoF
6 (0) [-] none 6 614400 B 145.783783 145.803780 50.000 fps ts mono/EoF
7 (1) [-] none 7 614400 B 145.803784 145.823768 49.998 fps ts mono/EoF
8 (2) [-] none 8 614400 B 145.823784 145.843768 50.000 fps ts mono/EoF
9 (3) [-] none 9 614400 B 145.843784 145.863797 50.000 fps ts mono/EoF
10 (4) [-] none 10 614400 B 145.863785 145.883781 49.998 fps ts mono/EoF
11 (5) [-] none 11 614400 B 145.883785 145.903782 50.000 fps ts mono/EoF
12 (0) [-] none 12 614400 B 145.903785 145.923770 50.000 fps ts mono/EoF
13 (1) [-] none 13 614400 B 145.923785 145.929529 50.000 fps ts mono/EoF

On STDERR:

Code: Select all

Exception
Source changed
Unmapped all buffers
Source changed
Unmapped all buffers

Does anybody have an idea why this happens?
Also please note, that when I disable overlay and run raspivid with proprietary driver in /boot/start_x.elf I get normal video with "cheap" board without any problem (and without sound non-v4l2 driver doesn't support sound.
Dear 6by9, please give us your respectable opinion!

P.S. Some similar log I found here: viewtopic.php?f=38&t=218138
There 6by9 says that

It sounds like the source isn't finding a mode that it likes.

I'm not sure if this is my case, as with the same EDID my original B100 works fine.
Video that demonstrates my problem:
https://youtu.be/LthGH5Y9F0g

Normal picture (using B100) from the same source:

[6by9]

The forum doesn't flag threads as new if you update an existing post, so I hadn't seen your daughterboard update. Glad it works.

The

Code: Select all

Exception
Source changed

bit is what it says - the source has changed timings.
The V4L2 driver polls the TC358743 once a second for status changes because the interrupt line isn't wired out on these boards. If the chip reports a resolution change then this gets signalled up the stack to allow the application to reconfigure.
In theory yavta responds to this signal and reconfigures the pipe for the new timings, but it's not a path I significantly tested, so it's quite possible that there is an issue in yavta with that.
The firmware doesn't support resolution changes, so it would just keep churning away at the wrong resolution.

At a guess there is going to be some other issue (I'd guess in the PLL circuitry again) that results in slightly unstable video reception. It would need a further chunk of circuit analysis to work if that was the case.

[idcidc]

6by9, thanks a lot for quick response!
I'll try to analyze PLL around 27MHz XTAL and will report results.
But what seems strange for me is that plain raspivid works fine providing video with normal resolution on the same board. May be this is due to raspivid is more "dumb" than yavta...

[6by9]

But what seems strange for me is that plain raspivid works fine providing video with normal resolution on the same board. May be this is due to raspivid is more "dumb" than yavta...

Yes, probably because I believe it asks the chip for the resolution once at the start, and then never again. If the chip decides there is a change then raspivid will keep receiving frames using the old parameters and get potentially a couple of corrupted frames, and then I'd guess the chip updates again back to the old settings and resumes as usual. You may well not notice it, although there may be a couple of dropped frames in there.

I'll try to look into why yavta doesn't handle the timing change properly - it appears to do the full unmap fine, but doesn't resume.

[idcidc]

I continue to investigate both "cheap" and "original" modules and observe some strange things. I've tried both modules with raspivid and got these results in RAW:

B100 module

8Mb lossless: http://stream.yg.kh.ua/x1/b100-bar_0_rgb.bmp
C779 module

8Mb lossless: http://stream.yg.kh.ua/x1/c779-bar_0_rgb.bmp

I've used https://github.com/Tee0125/yuvplayer/releases/tag/2.5.0 for decoding RAW YUV with parameters: custom size 1920x1088, color YUV420

As can be seen, B100 produces color bars with incorrect tone, while cheap C779 works fine and gives normal color bars. The same results I see on monitor connected to my Raspberry PI while raspivid runs.

Any ideas why this happens? Why does original brand board by Auvidea works worse than cheap adapter?

[6by9]

No idea, and I'll fall back on all use of tc358743 with the firmware drivers is unsupported.
If you can reproduce with the kernel drivers then I may investigate.

[idcidc]

Ok, I'll try to reproduce this with kernel driver. 6by9,which command will you recommend to capture raw data from V4L2 device?

[6by9]

Set an EDID with v4l2-ctl --set-edid
v4l2-ctl --set-dv-bt-timings query
v4l2-ctl --stream-mmap=3 --stream-to=filename --stream-count=5 --stream-skip=2
would skip 2 frames and then capture 5. Change those last two numbers as you see fit.
You probably want a skip of at least 1 as I believe the chip will immediately start capturing when told to, rather than waiting for the start of a new frame.

[6by9]

I do vaguely recall a similar report and someone proposed a set of magic register changes with no justification.
Ah https://github.com/6by9/raspi_tc358743/issues/1

[idcidc]

https://github.com/6by9/raspi_tc358743/issues/1

Great! Thanks a lot, I'll try this.

It looks a bit strange that on different "just carrier boards" as noted the same chip produces different results being initialized with exactly the same commands and even connected using the same cables etc.

Different revisions of TC358743 with different e.g.defaults? Counterfeit ICs?..

I've checked XTAL on my C779 board, I see clear 27MHz (exactly the same as on B100), FFT shows strong main frequency, so it looks like no problem with PLL (but I'm unsure, please give me an idea how to check PLL)

[idcidc]

6by9, I've tried to get RAW video from both B100 and C779 adapters and get stucked: when running

Code: Select all

v4l2-ctl --stream-mmap=3 --stream-to=filename --stream-count=100 --stream-skip=2

I successfully capture 100 frames 1280x720, BGR24 color.

YES, THE SAME RESULTS BOTH ON "ORIGINAL" B100 AND ON "CHEAP" C779!

In both cases delays between frames sometimes become longer (it looks like low fps or frame dropping on live videos of my fish tank). Possible it's due to delays while writing to SD-card or some other activity that interrupts main capture process. These delays I observe on B100 and on C779, so it doesn't look like the exclusive problem of "cheap" adapter.

I've repeated captures 3 times with full power down of Raspberry PI with attached adapters after each capture.
I've captured color bars generated by camcorder and live video of my fish tank in order to see if frames are captured monotonously.
As I understood, while capturing v4l2-ctl puts < character to STDERR for each captured frame.

EDID loaded to adapters (in all cases), I2S sound successfully enabled

Code: Select all

CTA-861 Header
  IT Formats Underscanned: yes
  Audio:                   yes
  YCbCr 4:4:4:             no
  YCbCr 4:2:2:             no

HDMI Vendor-Specific Data Block
  Physical Address:        3.0.0.0
  YCbCr 4:4:4 Deep Color:  no
  30-bit:                  no
  36-bit:                  no
  48-bit:                  no

CTA-861 Video Capability Descriptor
  RGB Quantization Range:  yes
  YCC Quantization Range:  no
  PT:                      Supports both over- and underscan
  IT:                      Supports both over- and underscan
  CE:                      Supports both over- and underscan

DV timings

Code: Select all

	Active width: 1280
	Active height: 720
	Total width: 1650
	Total height: 750
	Frame format: progressive
	Polarities: -vsync -hsync
	Pixelclock: 74250000 Hz (60.00 frames per second)
	Horizontal frontporch: 0
	Horizontal sync: 370
	Horizontal backporch: 0
	Vertical frontporch: 0
	Vertical sync: 30
	Vertical backporch: 0
	Standards: 
	Flags: 

For B100 & color bars, STDERR while capture:

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 44.44 fps
<<<<<<<<<<<<<<<<<<<<<< 29.81 fps
<<<<< 22.17 fps
<<<< 17.75 fps
<<< 5.27 fps
< 5.32 fps
<<<<<<<<<<<<<<<<<<<<<

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 49.10 fps
<<<<<<<<<<<<<<<<<<< 31.81 fps
<<< 23.84 fps
<<<< 18.29 fps
<<< 5.77 fps
< 5.47 fps
<<<<<<<<<<<<<<<<<< 6.53 fps
<<<

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 49.24 fps
<<<<<<<<<<<<<< 22.58 fps
< 14.77 fps
<<< 13.50 fps
< 4.65 fps
<<< 4.44 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

For B100 & live video of fish tank, STDERR while capture:

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 49.31 fps
<<<<<<<<<<< 19.27 fps
<<<<< 16.10 fps
<< 5.34 fps
< 4.91 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 47.54 fps
<<<<<<<< 18.10 fps
<<<<<<<<<<<<<< 17.75 fps
<<<< 5.15 fps
< 3.89 fps
<<<<<< 4.01 fps
<<<<<<<<<<<<<<<<<<<

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 49.42 fps
<<<<<<<<<<<<<<<<< 19.82 fps
<<<< 17.54 fps
<<<< 5.28 fps
< 5.02 fps
< 4.65 fps
<<<<<<<<<<<<<<<<<<<<<< 5.82 fps
<<

For C779 & color bars, STDERR while capture:

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 50.75 fps
<<<<<<<<<<<<<<< 4.90 fps
<<<<<<<<<<<<<<<<<<<<<<<<<< 6.57 fps
<<<<<<<<<

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 49.58 fps
<<<<<<<<<<<<<<<<< 20.34 fps
<<<<< 16.51 fps
<<< 5.36 fps
< 5.42 fps
<<<<<<<<<<<<<<<<<<<<<<<<<

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 21.75 fps
<<<<<<<<<<<<<<<<<<< 26.65 fps
<<<<<<<<<<<<<<<< 16.23 fps
<<<< 4.73 fps
<<<< 4.52 fps
<<<<<<<<<<<<<<<<<<<<<<<

For C779 & live video of fish tank, STDERR while capture:

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 48.31 fps
<<<<<<<<<<<<<<<<<<<< 33.96 fps
<<<< 23.81 fps
<< 6.41 fps
< 6.05 fps
<<<<<<<<<<<<<<<<<<<< 7.38 fps
<<<<<

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 48.47 fps
<<<<<<<<<<<<<<<<< 19.23 fps
<<<< 17.17 fps
<<< 5.18 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<

Code: Select all

New timings found
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 49.56 fps
<<<<<<<<<<<<<<<<< 20.34 fps
<<<<< 16.70 fps
<< 4.68 fps
<<<<<<<< 5.12 fps
<<<<<<<<<<<<<<<<<<<

Full raw captures are public shared on Google Drive: https://drive.google.com/drive/folders/ ... sp=sharing
If will use yuvplayer please note that it doesn't support BGR24, so frames can be viewed in RGB24, 720p, with incorrect colors (red swaps blue). That's OK for test purposes.

But the problem still persists: yavta doesn't render to MMAL when running with "cheap" C779 adapter. While v4l2-ctl captures frames absolutely identically on any adapter...
6by9, hope for your help very much!:)
Any ideas what to check else?..

[6by9]

V4l2-ctl will stall whilst saving files.

I'll try to remember to look at the datasheet to see what those registers are. I seem to recall they are related to the colour conversion matrixes, but I don't think there is an auto mode that could be misdetecting.

As for the extraneous timing changes, I can't say. All I can do is look at fixing yavta to resume afterwards.

And please remember that all of these are 3rd part products - we don't make them, or make any money from them. In many ways it would be nice if the manufacturers took an interest in fixing their hardware, but that's unlikely ever to happen.

[idcidc]

And please remember that all of these are 3rd part products - we don't make them, or make any money from them. In many ways it would be nice if the manufacturers took an interest in fixing their hardware, but that's unlikely ever to happen.

Yes, ofcourse, it's clear for me. I'm just trying to learn and explain to myself why these strange things occur (I mean different behavior with the same (?) main IC (TC358743). And while it's absolutely predictable with sound issue on C779, the problem with yavta and the behavior of raspivid looks strange.

[6by9]

So based on the previous issue that had been raised, I'm looking at the VOUT_SET2 in the tc358743 driver.

COLORMODE is always set to AUTO (1).
The datasheet contradicts the names given in the driver though.
0x00 is "through mode" (RGB888 output)
0x01 is "Enable RGB888 to YUV422 conversion (Fixed colour output)
0x02 is reserved
0x03 is "Enable RGB888 to YUV422 Conversion using coefficients in registers 0x85b0-0x85c1"

The recommended settings for conversion are 1 "Use internal default setting" for RGB888 to YUV422, but 3 for RGB888 to YUV444.

Register 0x8576 does allow configuration of whether full or limited range and RGB, BT601 or BT709 is wanted on the output, as long as 0x8573 COLORMODE is NOT 0x00 (Through). The kernel driver does appear to sensibly set that to BT601 limited range for UYVY, or RGB full range for RGB.

So I don't see an automatic colour format switch anywhere in that lot. There is the possibility that the HDMI source is putting out RGB limited range and that isn't being expanded properly in some cases.

Looking at your raws, b100-bars-100-2.raw vs c779-bars-100-2.raw are nearly identical. I use an app called Vooya on x86 Linux, and it allows you to magnify the image and read the RGB values of each pixel, and to do diffs between two images. There are a couple of bands of change at the edges of some bars, which probably implies there is a filter somewhere that is still active.
The blacks at the bottom are also reading as 1,0,1 from the C779, but 0,0,0 from the B100, and white as 254,253,254 vs 254,254,254 - again possibly a conversion rounding error somewhere.
If you play through each of the clips, there also seems to be a small amount of bounce up and down of the horizontal lines, almost as if the source were interlaced and giving alternate fields.

I see no discrepancies in the colours between those clips, nor the -1, -3, nor x-3 clips that I've looked at.

[6by9]

My only other thought is to run "v4l2-ctl --log-status" to dump out the internal state of the driver in each case. That should include all the details of the HDMI AVI Infoframe which should describe the incoming video.

[idcidc]

My only other thought is to run "v4l2-ctl --log-status" to dump out the internal state of the driver in each case. That should include all the details of the HDMI AVI Infoframe which should describe the incoming video.

Done!
Environment: Raspberry PI 3 with connected HDMI-CSI adapter & camcorder 720p60 with color bars. Getting log twice: just after power-on and after EDID's loading.

B100 right after power-on:

Code: Select all

Status Log:

   [  118.535727] unicam 3f801000.csi1: =================  START STATUS  =================
   [  118.538349] tc358743 4-000f: -----Chip status-----
   [  118.539316] tc358743 4-000f: Chip ID: 0x00
   [  118.540283] tc358743 4-000f: Chip revision: 0x00
   [  118.540292] tc358743 4-000f: Reset: IR: 1, CEC: 1, CSI TX: 0, HDMI: 0
   [  118.540297] tc358743 4-000f: Sleep mode: off
   [  118.540303] tc358743 4-000f: Cable detected (+5V power): yes
   [  118.541127] tc358743 4-000f: DDC lines enabled: yes
   [  118.541951] tc358743 4-000f: Hotplug enabled: no
   [  118.542916] tc358743 4-000f: CEC enabled: no
   [  118.542922] tc358743 4-000f: -----Signal status-----
   [  118.542927] tc358743 4-000f: TMDS signal detected: yes
   [  118.542949] tc358743 4-000f: Stable sync signal: yes
   [  118.542953] tc358743 4-000f: PHY PLL locked: yes
   [  118.542958] tc358743 4-000f: PHY DE detected: yes
   [  118.553576] tc358743 4-000f: Detected format: 1280x720p60.0 (1650x750)
   [  118.553585] tc358743 4-000f: horizontal: fp = 0, -sync = 370, bp = 0
   [  118.553592] tc358743 4-000f: vertical: fp = 0, -sync = 30, bp = 0
   [  118.553598] tc358743 4-000f: pixelclock: 74250000
   [  118.553606] tc358743 4-000f: flags (0x0):
   [  118.553612] tc358743 4-000f: standards (0x0):
   [  118.553621] tc358743 4-000f: Configured format: 640x480p59.94 (800x525)
   [  118.553628] tc358743 4-000f: horizontal: fp = 16, -sync = 96, bp = 48
   [  118.553634] tc358743 4-000f: vertical: fp = 10, -sync = 2, bp = 33
   [  118.553639] tc358743 4-000f: pixelclock: 25175000
   [  118.553648] tc358743 4-000f: flags (0x80): HAS_CEA861_VIC
   [  118.553654] tc358743 4-000f: standards (0x3): CEA DMT
   [  118.553659] tc358743 4-000f: CEA-861 VIC: 1
   [  118.553663] tc358743 4-000f: -----CSI-TX status-----
   [  118.553669] tc358743 4-000f: Lanes needed: 1
   [  118.553674] tc358743 4-000f: Lanes in use: 1
   [  118.554644] tc358743 4-000f: Waiting for particular sync signal: no
   [  118.555608] tc358743 4-000f: Transmit mode: no
   [  118.556572] tc358743 4-000f: Receive mode: no
   [  118.557537] tc358743 4-000f: Stopped: no
   [  118.557542] tc358743 4-000f: Color space: RGB 888 24-bit
   [  118.558364] tc358743 4-000f: -----HDMI status-----
   [  118.558369] tc358743 4-000f: HDCP encrypted content: no
   [  118.558376] tc358743 4-000f: Input color space: YCbCr 709 limited range
   [  118.559197] tc358743 4-000f: AV Mute: off
   [  118.560022] tc358743 4-000f: Deep color mode: 8-bits per channel
   [  118.563979] tc358743 4-000f: HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13
   [  118.563988] tc358743 4-000f:     colorspace: YCbCr 4:2:2
   [  118.563996] tc358743 4-000f:     scan mode: Overscan
   [  118.564003] tc358743 4-000f:     colorimetry: ITU709
   [  118.564011] tc358743 4-000f:     picture aspect: 16:9
   [  118.564018] tc358743 4-000f:     active aspect: Same as Picture
   [  118.564026] tc358743 4-000f:     itc: No Data
   [  118.564034] tc358743 4-000f:     extended colorimetry: xvYCC 601
   [  118.564042] tc358743 4-000f:     quantization range: Default
   [  118.564050] tc358743 4-000f:     nups: Unknown Non-uniform Scaling
   [  118.564060] tc358743 4-000f:     video code: 4
   [  118.564068] tc358743 4-000f:     ycc quantization range: Limited
   [  118.564076] tc358743 4-000f:     hdmi content type: Graphics
   [  118.564083] tc358743 4-000f:     pixel repeat: 0
   [  118.564092] tc358743 4-000f:     bar top 0, bottom 0, left 0, right 0
   [  118.564098] unicam 3f801000.csi1: -----Receiver status-----
   [  118.564104] unicam 3f801000.csi1: V4L2 width/height:   16x16
   [  118.564110] unicam 3f801000.csi1: Mediabus format:     0000100a
   [  118.564115] unicam 3f801000.csi1: V4L2 format:         RGB3
   [  118.564122] unicam 3f801000.csi1: Unpacking/packing:   0 / 0
   [  118.564126] unicam 3f801000.csi1: ----Live data----
   [  118.564131] unicam 3f801000.csi1: Programmed stride:      0
   [  118.564137] unicam 3f801000.csi1: Detected resolution: 0x0
   [  118.564142] unicam 3f801000.csi1: Write pointer:       00000000
   [  118.564147] unicam 3f801000.csi1: ==================  END STATUS  ==================

... then I've loaded EDID and then got:
B100 after EDID's loading:

Code: Select all

Status Log:

   [  142.990906] unicam 3f801000.csi1: =================  START STATUS  =================
   [  142.993565] tc358743 4-000f: -----Chip status-----
   [  142.994531] tc358743 4-000f: Chip ID: 0x00
   [  142.995496] tc358743 4-000f: Chip revision: 0x00
   [  142.995504] tc358743 4-000f: Reset: IR: 1, CEC: 1, CSI TX: 0, HDMI: 0
   [  142.995510] tc358743 4-000f: Sleep mode: off
   [  142.995516] tc358743 4-000f: Cable detected (+5V power): yes
   [  142.996335] tc358743 4-000f: DDC lines enabled: yes
   [  142.997156] tc358743 4-000f: Hotplug enabled: no
   [  142.998122] tc358743 4-000f: CEC enabled: no
   [  142.998127] tc358743 4-000f: -----Signal status-----
   [  142.998132] tc358743 4-000f: TMDS signal detected: yes
   [  142.998138] tc358743 4-000f: Stable sync signal: yes
   [  142.998142] tc358743 4-000f: PHY PLL locked: yes
   [  142.998147] tc358743 4-000f: PHY DE detected: yes
   [  143.008806] tc358743 4-000f: Detected format: 1280x720p60.0 (1650x750)
   [  143.008815] tc358743 4-000f: horizontal: fp = 0, -sync = 370, bp = 0
   [  143.008822] tc358743 4-000f: vertical: fp = 0, -sync = 30, bp = 0
   [  143.008827] tc358743 4-000f: pixelclock: 74250000
   [  143.008836] tc358743 4-000f: flags (0x0):
   [  143.008842] tc358743 4-000f: standards (0x0):
   [  143.008851] tc358743 4-000f: Configured format: 640x480p59.94 (800x525)
   [  143.008858] tc358743 4-000f: horizontal: fp = 16, -sync = 96, bp = 48
   [  143.008864] tc358743 4-000f: vertical: fp = 10, -sync = 2, bp = 33
   [  143.008869] tc358743 4-000f: pixelclock: 25175000
   [  143.008878] tc358743 4-000f: flags (0x80): HAS_CEA861_VIC
   [  143.008884] tc358743 4-000f: standards (0x3): CEA DMT
   [  143.008889] tc358743 4-000f: CEA-861 VIC: 1
   [  143.008894] tc358743 4-000f: -----CSI-TX status-----
   [  143.008899] tc358743 4-000f: Lanes needed: 1
   [  143.008904] tc358743 4-000f: Lanes in use: 1
   [  143.009872] tc358743 4-000f: Waiting for particular sync signal: no
   [  143.010847] tc358743 4-000f: Transmit mode: no
   [  143.011815] tc358743 4-000f: Receive mode: no
   [  143.012779] tc358743 4-000f: Stopped: no
   [  143.012784] tc358743 4-000f: Color space: RGB 888 24-bit
   [  143.013604] tc358743 4-000f: -----HDMI status-----
   [  143.013614] tc358743 4-000f: HDCP encrypted content: no
   [  143.013620] tc358743 4-000f: Input color space: YCbCr 709 limited range
   [  143.014442] tc358743 4-000f: AV Mute: off
   [  143.015264] tc358743 4-000f: Deep color mode: 8-bits per channel
   [  143.019221] tc358743 4-000f: HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13
   [  143.019230] tc358743 4-000f:     colorspace: YCbCr 4:2:2
   [  143.019238] tc358743 4-000f:     scan mode: Overscan
   [  143.019246] tc358743 4-000f:     colorimetry: ITU709
   [  143.019255] tc358743 4-000f:     picture aspect: 16:9
   [  143.019263] tc358743 4-000f:     active aspect: Same as Picture
   [  143.019271] tc358743 4-000f:     itc: No Data
   [  143.019280] tc358743 4-000f:     extended colorimetry: xvYCC 601
   [  143.019288] tc358743 4-000f:     quantization range: Default
   [  143.019296] tc358743 4-000f:     nups: Unknown Non-uniform Scaling
   [  143.019303] tc358743 4-000f:     video code: 4
   [  143.019314] tc358743 4-000f:     ycc quantization range: Limited
   [  143.019322] tc358743 4-000f:     hdmi content type: Graphics
   [  143.019329] tc358743 4-000f:     pixel repeat: 0
   [  143.019339] tc358743 4-000f:     bar top 0, bottom 0, left 0, right 0
   [  143.019345] unicam 3f801000.csi1: -----Receiver status-----
   [  143.019351] unicam 3f801000.csi1: V4L2 width/height:   16x16
   [  143.019356] unicam 3f801000.csi1: Mediabus format:     0000100a
   [  143.019362] unicam 3f801000.csi1: V4L2 format:         RGB3
   [  143.019369] unicam 3f801000.csi1: Unpacking/packing:   0 / 0
   [  143.019374] unicam 3f801000.csi1: ----Live data----
   [  143.019379] unicam 3f801000.csi1: Programmed stride:      0
   [  143.019384] unicam 3f801000.csi1: Detected resolution: 0x0
   [  143.019390] unicam 3f801000.csi1: Write pointer:       00000000
   [  143.019396] unicam 3f801000.csi1: ==================  END STATUS  ==================

The same with C779:
C779 right after power-on:

Code: Select all

Status Log:

   [  100.592629] unicam 3f801000.csi1: =================  START STATUS  =================
   [  100.595251] tc358743 4-000f: -----Chip status-----
   [  100.596220] tc358743 4-000f: Chip ID: 0x00
   [  100.597184] tc358743 4-000f: Chip revision: 0x00
   [  100.597192] tc358743 4-000f: Reset: IR: 1, CEC: 1, CSI TX: 0, HDMI: 0
   [  100.597197] tc358743 4-000f: Sleep mode: off
   [  100.597204] tc358743 4-000f: Cable detected (+5V power): yes
   [  100.598025] tc358743 4-000f: DDC lines enabled: yes
   [  100.598845] tc358743 4-000f: Hotplug enabled: no
   [  100.599810] tc358743 4-000f: CEC enabled: no
   [  100.599815] tc358743 4-000f: -----Signal status-----
   [  100.599820] tc358743 4-000f: TMDS signal detected: no
   [  100.599825] tc358743 4-000f: Stable sync signal: no
   [  100.599830] tc358743 4-000f: PHY PLL locked: no
   [  100.599835] tc358743 4-000f: PHY DE detected: yes
   [  100.600658] tc358743 4-000f: No video detected
   [  100.600671] tc358743 4-000f: Configured format: 640x480p59.94 (800x525)
   [  100.600678] tc358743 4-000f: horizontal: fp = 16, -sync = 96, bp = 48
   [  100.600685] tc358743 4-000f: vertical: fp = 10, -sync = 2, bp = 33
   [  100.600691] tc358743 4-000f: pixelclock: 25175000
   [  100.600700] tc358743 4-000f: flags (0x80): HAS_CEA861_VIC
   [  100.600707] tc358743 4-000f: standards (0x3): CEA DMT
   [  100.600712] tc358743 4-000f: CEA-861 VIC: 1
   [  100.600716] tc358743 4-000f: -----CSI-TX status-----
   [  100.600722] tc358743 4-000f: Lanes needed: 1
   [  100.600728] tc358743 4-000f: Lanes in use: 1
   [  100.601703] tc358743 4-000f: Waiting for particular sync signal: no
   [  100.602673] tc358743 4-000f: Transmit mode: no
   [  100.603638] tc358743 4-000f: Receive mode: no
   [  100.604604] tc358743 4-000f: Stopped: no
   [  100.604610] tc358743 4-000f: Color space: RGB 888 24-bit
   [  100.605430] tc358743 4-000f: -----DVI-D status-----
   [  100.605436] tc358743 4-000f: HDCP encrypted content: no
   [  100.605442] tc358743 4-000f: Input color space: RGB full range
   [  100.606264] unicam 3f801000.csi1: -----Receiver status-----
   [  100.606272] unicam 3f801000.csi1: V4L2 width/height:   16x16
   [  100.606278] unicam 3f801000.csi1: Mediabus format:     0000100a
   [  100.606284] unicam 3f801000.csi1: V4L2 format:         RGB3
   [  100.606296] unicam 3f801000.csi1: Unpacking/packing:   0 / 0
   [  100.606300] unicam 3f801000.csi1: ----Live data----
   [  100.606305] unicam 3f801000.csi1: Programmed stride:      0
   [  100.606311] unicam 3f801000.csi1: Detected resolution: 0x0
   [  100.606316] unicam 3f801000.csi1: Write pointer:       00000000
   [  100.606322] unicam 3f801000.csi1: ==================  END STATUS  ==================

C779 after EDID's loading:

Code: Select all

Status Log:

   [  137.799059] unicam 3f801000.csi1: =================  START STATUS  =================
   [  137.801805] tc358743 4-000f: -----Chip status-----
   [  137.802780] tc358743 4-000f: Chip ID: 0x00
   [  137.803749] tc358743 4-000f: Chip revision: 0x00
   [  137.803756] tc358743 4-000f: Reset: IR: 1, CEC: 1, CSI TX: 0, HDMI: 0
   [  137.803761] tc358743 4-000f: Sleep mode: off
   [  137.803767] tc358743 4-000f: Cable detected (+5V power): yes
   [  137.804587] tc358743 4-000f: DDC lines enabled: yes
   [  137.805408] tc358743 4-000f: Hotplug enabled: yes
   [  137.806373] tc358743 4-000f: CEC enabled: no
   [  137.806378] tc358743 4-000f: -----Signal status-----
   [  137.806383] tc358743 4-000f: TMDS signal detected: yes
   [  137.806389] tc358743 4-000f: Stable sync signal: yes
   [  137.806393] tc358743 4-000f: PHY PLL locked: yes
   [  137.806398] tc358743 4-000f: PHY DE detected: yes
   [  137.817023] tc358743 4-000f: Detected format: 1280x720p60.0 (1650x750)
   [  137.817033] tc358743 4-000f: horizontal: fp = 0, -sync = 370, bp = 0
   [  137.817041] tc358743 4-000f: vertical: fp = 0, -sync = 30, bp = 0
   [  137.817047] tc358743 4-000f: pixelclock: 74250000
   [  137.817055] tc358743 4-000f: flags (0x0):
   [  137.817062] tc358743 4-000f: standards (0x0):
   [  137.817070] tc358743 4-000f: Configured format: 640x480p59.94 (800x525)
   [  137.817077] tc358743 4-000f: horizontal: fp = 16, -sync = 96, bp = 48
   [  137.817084] tc358743 4-000f: vertical: fp = 10, -sync = 2, bp = 33
   [  137.817089] tc358743 4-000f: pixelclock: 25175000
   [  137.817098] tc358743 4-000f: flags (0x80): HAS_CEA861_VIC
   [  137.817104] tc358743 4-000f: standards (0x3): CEA DMT
   [  137.817109] tc358743 4-000f: CEA-861 VIC: 1
   [  137.817114] tc358743 4-000f: -----CSI-TX status-----
   [  137.817120] tc358743 4-000f: Lanes needed: 1
   [  137.817125] tc358743 4-000f: Lanes in use: 1
   [  137.818092] tc358743 4-000f: Waiting for particular sync signal: no
   [  137.819057] tc358743 4-000f: Transmit mode: no
   [  137.820022] tc358743 4-000f: Receive mode: no
   [  137.820996] tc358743 4-000f: Stopped: no
   [  137.821002] tc358743 4-000f: Color space: RGB 888 24-bit
   [  137.821831] tc358743 4-000f: -----HDMI status-----
   [  137.821837] tc358743 4-000f: HDCP encrypted content: no
   [  137.821844] tc358743 4-000f: Input color space: RGB limited range
   [  137.822673] tc358743 4-000f: AV Mute: off
   [  137.823499] tc358743 4-000f: Deep color mode: 8-bits per channel
   [  137.827452] tc358743 4-000f: HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13
   [  137.827460] tc358743 4-000f:     colorspace: RGB
   [  137.827468] tc358743 4-000f:     scan mode: Overscan
   [  137.827476] tc358743 4-000f:     colorimetry: ITU709
   [  137.827483] tc358743 4-000f:     picture aspect: 16:9
   [  137.827491] tc358743 4-000f:     active aspect: Same as Picture
   [  137.827499] tc358743 4-000f:     itc: No Data
   [  137.827507] tc358743 4-000f:     extended colorimetry: xvYCC 601
   [  137.827515] tc358743 4-000f:     quantization range: Default
   [  137.827522] tc358743 4-000f:     nups: Unknown Non-uniform Scaling
   [  137.827530] tc358743 4-000f:     video code: 4
   [  137.827538] tc358743 4-000f:     ycc quantization range: Limited
   [  137.827546] tc358743 4-000f:     hdmi content type: Graphics
   [  137.827553] tc358743 4-000f:     pixel repeat: 0
   [  137.827562] tc358743 4-000f:     bar top 0, bottom 0, left 0, right 0
   [  137.827568] unicam 3f801000.csi1: -----Receiver status-----
   [  137.827574] unicam 3f801000.csi1: V4L2 width/height:   16x16
   [  137.827580] unicam 3f801000.csi1: Mediabus format:     0000100a
   [  137.827586] unicam 3f801000.csi1: V4L2 format:         RGB3
   [  137.827592] unicam 3f801000.csi1: Unpacking/packing:   0 / 0
   [  137.827596] unicam 3f801000.csi1: ----Live data----
   [  137.827601] unicam 3f801000.csi1: Programmed stride:      0
   [  137.827607] unicam 3f801000.csi1: Detected resolution: 0x0
   [  137.827612] unicam 3f801000.csi1: Write pointer:       00000000
   [  137.827618] unicam 3f801000.csi1: ==================  END STATUS  ==================

[6by9]

As to yavta failing on "source changed" exception, using a Pi as a source and explicitly changing the mode, I get

Code: Select all

321 (1) [-] none 321 4147200 B 11111.239985 11111.256719 60.006 fps ts mono/EoF
322 (2) [-] none 322 4147200 B 11111.256652 11111.273396 59.999 fps ts mono/EoF
323 (3) [-] none 323 4147200 B 11111.273321 11111.283392 59.992 fps ts mono/EoF
Exception
Source changed
QUERY_DV_TIMINGS returned 1280x720 pixclk 74250000
Failed to set DV timings
Unmapped all buffers
Source changed
QUERY_DV_TIMINGS returned 1280x720 pixclk 74250000
Failed to set DV timings
Unmapped all buffers

yavta hasn't stopped the device streaming, therefore the call to set the timings fails as it'll update the device format, and you can't do that whilst it is streaming.

[idcidc]

The first difference I see that in initial state after power-on C779 sees no signal (while camcorder is connected and active), while B100 sees signal:
B100:
[ 118.542922] tc358743 4-000f: -----Signal status-----
[ 118.542927] tc358743 4-000f: TMDS signal detected: yes
[ 118.542949] tc358743 4-000f: Stable sync signal: yes
[ 118.542953] tc358743 4-000f: PHY PLL locked: yes
[ 118.542958] tc358743 4-000f: PHY DE detected: yes
[ 118.553576] tc358743 4-000f: Detected format: 1280x720p60.0 (1650x750)

C779:
[ 100.599815] tc358743 4-000f: -----Signal status-----
[ 100.599820] tc358743 4-000f: TMDS signal detected: no
[ 100.599825] tc358743 4-000f: Stable sync signal: no
[ 100.599830] tc358743 4-000f: PHY PLL locked: no
[ 100.599835] tc358743 4-000f: PHY DE detected: yes
[ 100.600658] tc358743 4-000f: No video detected

...and then, after loading of EDID, C779 starts to see video:

Code: Select all

   [  137.806378] tc358743 4-000f: -----Signal status-----
   [  137.806383] tc358743 4-000f: TMDS signal detected: yes
   [  137.806389] tc358743 4-000f: Stable sync signal: yes
   [  137.806393] tc358743 4-000f: PHY PLL locked: yes
   [  137.806398] tc358743 4-000f: PHY DE detected: yes
   [  137.817023] tc358743 4-000f: Detected format: 1280x720p60.0 (1650x750)

[idcidc]

yavta hasn't stopped the device streaming, therefore the call to set the timings fails as it'll update the device format, and you can't do that whilst it is streaming.

And what is workaround for this? Or just "not to set timings while streaming"?;)

[idcidc]

There are a couple of bands of change at the edges of some bars, which probably implies there is a filter somewhere that is still active.
The blacks at the bottom are also reading as 1,0,1 from the C779, but 0,0,0 from the B100, and white as 254,253,254 vs 254,254,254 - again possibly a conversion rounding error somewhere.

So C779 looks less accurate

As I understand, both HDMI and CSI are digital interfaces, no A/D and D/A conversiaons are performed.
Please explain, what conversion rounding error we are talking about in case of raw data dump? Even in case of internal colorspace processing inside TC358743 white should remain white (with equal R,G,B components) and black should remain black (or deep-dark-grey). Am I wrong?

[6by9]

yavta hasn't stopped the device streaming, therefore the call to set the timings fails as it'll update the device format, and you can't do that whilst it is streaming.

And what is workaround for this? Or just "not to set timings while streaming"?;)

It needs to stop streaming if it is already, set the timings, and then resume again. Not a huge change, but it may affect other bits around it.

[6by9]

There are a couple of bands of change at the edges of some bars, which probably implies there is a filter somewhere that is still active.
The blacks at the bottom are also reading as 1,0,1 from the C779, but 0,0,0 from the B100, and white as 254,253,254 vs 254,254,254 - again possibly a conversion rounding error somewhere.

So C779 looks less accurate

As I understand, both HDMI and CSI are digital interfaces, no A/D and D/A conversiaons are performed.
Please explain, what conversion rounding error we are talking about in case of raw data dump? Even in case of internal colorspace processing inside TC358743 white should remain white (with equal R,G,B components) and black should remain black (or deep-dark-grey). Am I wrong?

The chip has to accept RGB888, YUV444, and YUV422 as input, each of which has a full (0-255) or limited (16-235) range option, and the YUV options can be either with BT601 or BT709 colour primaries.
On the output side it is able to put out RGB888, YUV444, or YUV422 and again I believe it can do full or limited modes, and BT601 or BT709 primaries.

To convert to or from YUV422 requires some form of filtering on the chroma planes to deal with the horizontal subsampling.
The conversions between RGB and YUV require matrix transforms. Now those should be hard coded in the silicon and predicatble, but mixed in with multiple tap filters they may not be.

The only mode where the pixels should be totally untouched would be with VOUT_SET2 having colormode set to 0 for passthrough, but the kernel driver never does that. You then also have to have your app deal with the fact that the incoming data varies in range and colour primary.