_0andriy_: Perhaps tell the author how you felt? I assume most of the people aren't nasty by purpose. Perhaps the author has a possibility of learning something about interaction? With some good luck you both can, and it'll make future interaction easier :) (What are the chances that author was me?)
I wouldn't mind having also an off-list mail if people felt my communication being "sub-optimal" :)
pinchartl: bemug46: In my (not always) humble (enough) opinion, the original 5-line version was superior what comes to the documentation. Packing all that information in "- const: 1" requires the reader to be fairly capable with reading the bindings, whereas the explicit 'maxItems' is easier to understand
pinchartl: Most of the ice has melted from the roads by now, but there's still snow. Nights are still below zero which makes ice to re-appear at morning. Besides, it's still too cold for a spoiled brat like me to drive my motorcycle ;)
Time to head to the office. Have a fun day(*1) peeps!  [1]: Please, apply your local timezone.
I have a weird question, but, for limited range RGB, the valid range is reduced from 0-255 to 16-235, but how are "valid" values are scaled between full and limited range?
does limited range just consider every below 16 as black, and above 235 as white, but the intermediate values match the same colors, or do you have a conversion formula?
mripard: yes, <= 16 is black, >= 235 is white. To map limited range to full range you would just scale the values: (lim - 16) * 255 / 219.
yeah, my question was about the scaling part, if there was one or not :)
but you answered already :)
I guess I have another question for you then. I'm using a small board with a tc358743, connected on one end to a RPi4 HDMI output, and the other to a RPi4 CSI input. I have a custom KMS and v4l2 application to deal with the output and capture. It works fine. However, if I swap the bridge board in the middle for one with the same bridge but from another vendor, I'm getting limited
vs full range issues.
so I guess there's a difference in the bridge revision or whatever. Do you know how it's supposed to be handled in that bridge?
is it derived from the EDIDs, or is there some configuration?
So both vendors use the tc358743? Is there a difference in the number of lanes that are connected? That will affect the max resolution, and that can affect the chosen quantization range of the output.
yes, both use the tc358743
and it's the same number of lanes 
I'm running at 720p/60fps, and the Pi4 maxes out at 1080p/50fps so we should have some spare room on the bus too 
I assume you set the same EDID for both vendors?
yes 
the only thing that changes really is the bridge board itself (plus the ribbon cable from the board to the "capture" Pi4), the kernel, applications, etc. on both end are identical 
Run v4l2-ctl --log-status while capturing video, try that for both vendors. See if there is a difference between the two.
ack, I'll do that, thanks :)
mvaittin I'm biaised since the first version I came up with is obviously the one I thought was the best ;) But imo it's also part of the process to comply with maintainers requests. It's their subsystem so they know best what is better in the long term
bemug46: definitely. I am not trying to suggest you to try fighting the maintainers - and if I did, I did it in email :) I just voiced my opinion that the 'modern' yaml bindings are slowly getting less and less documentary while emphasizing validation and minimalism.
mripard: you have weird issues :-)
pinchartl: tell me about it
hverkuil: https://paste.ack.tf/c0c810@raw
they are identical except for the Input color space, colorimetry, and quantization range fields 
the last two don't make much sense to me, I swap bridges while the video output is active so I keep the same video feed. The infoframe aren't changing either.
but the content stays the same even if I restart the KMS application, so that's not the culprit
For the BROKEN version, the AVI InfoFrame says "quantization range: Default", for the WORKING version it says: "quantization range: Full"
So the difference comes from the video source: for some reason it explicitly selects full range, and in the other case it is left as default.
the source doesn't change in both cases. Like it literally stays the same, it's the same modeset, with the same parameters and the same infoframes 
the application I have so far doesn't react to hotplug events, so it just keps the HDMI controller running when it's disconnected and reconnected
Well, the tc358743 really sees different AVI InfoFrames. And that also explains the limited/full range difference.
Since the infoframes that the RPi transmits are now reported in debugfs, have you looked at that?
that's a good idea, let me try