we face an issue similar to
The main difference is that we deactivated the graphical interface using the following command:
sudo systemctl set-default multi-user.target
So setting the color range in xorg.conf is not an option to switch to full range. According to
the color range is set in DC driver which is located in the directory Linux_for_Tegra/sources/kernel/nvidia/drivers/video/tegra/dc (sources are synced using the script provided with SDK Manager). Can you narrow it down to a particular file in this directory?
We also use a Magewell USB frame grabber to capture the HDMI output of the TX2. The Magewell USB frame grabber is able to capture full range and tells us that the color range/quantization of the video stream from the TX2 (which is the input of the Magewell USB frame grabber) is limited range.
A GStreamer pipeline is used to capture the input with nvv4l2camerasrc, convert the pixelformat with nvvidconv and output it on HDMI using nvoverlaysink. This is the pipeline:
gst-launch-1.0 -e nvv4l2camerasrc device=/dev/video0 ! 'video/x-raw(memory:NVMM), format=(string)BGRx, width=(int)1920, height=(int)1080, framerate=(fraction)30/1' ! nvvidconv ! 'video/x-raw(memory:NVMM), format=(string)RGBA' ! nvoverlaysink
First of all we have problems figuring out how the EDID is connected to the color range. Does the EDID contain information about the color range/quantization? If so, which byte is related to the color range?
We secured that the input is captured with full range.
Your edid has a “vmode” and it has one field to tell whether full range or limited range is supported.
kernel/nvidia/drivers/video/tegra/dc/hdmi2.0.c → tegra_hdmi_get_rgb_quant
thanks for your quick answer!
We checked the EDID specification and came across the flag sRGB Standard is the default color space.
Is this flag used to extract color range information for the vmode variable in struct fb_videomode defined in source file Linux_for_Tegra/sources/kernel/kernel-4.9/include/linux/fb.h? If not, can you explain how the information is extracted from the EDID (which byte of the EDID)?
Is there documentation available regarding the structure of the vmode variable?
I also noticed that after disabling the graphical interface (window system) using
sudo systemctl set-default multi-user.target
the HDMI DC driver is not initialized. The appended image shows the output of dmesg after unplugging and plugging HDMI. The lines VMODE and hdmi->dc->initialized are outputs I added at the beginning of the tegra_hdmi_get_rgb_quant() function. Also, the line tegradc 15210000.nvdisplay shows that YCC is used instead of RGB (I suppose this is independent from graphical interface. I haven’t been able to test it yet. First thing I will try tomorrow).
Actually, I think you need to know that… in most case, it is not the kernel to make the decision. It is the userspace tool to decide what configuration kernel should use.
For example, when you are in graphic mode, it is the Xorg to decide which mode (resolution) to use. Kernel just reads the EDID and show the Xorg the list. The one chooses the mode is Xorg, not kernel.
Similar case to your color range problem. Xorg will decide which range to use.
Since you disabled the graphic, which means Xorg is being disabled, you should decide which userspace tool you want to use to control the kernel.
An easy way to use is running the gst sink node.
gst-launch-1.0 videotestsrc ! 'video/x-raw, width=800,height=600, framerates=60/1' ! nvvidconv ! nvcompositor ! nvdrmvideosink set-mode=1 color_range=1 //LIMITED COLOR RANGE
gst-launch-1.0 videotestsrc ! 'video/x-raw, width=800,height=600, framerates=60/1' ! nvvidconv ! nvcompositor ! nvdrmvideosink set-mode=1 color_range=0 //FULL RANGE
I already figured out that the EDID is read by the Kernel which passes the information to the application in userspace. But I haven’t noticed the nvdrmvideosink has an option to set the color range. nv3dsink and nvoverlaysink don’t support this option. Thank you for that!
Nevertheless, it is important for us to understand how the information about the color range is extracted from the EDID. We are developing devices for capturing video streams from an automotive video link and stream it over HDMI. We are captruing in full range and need pixel exact streaming over HDMI. I can’t find any reference in the EDID specification about color range so I’m wondering if the EDID is holding this information.
E-EDID A.2_revised_2020.pdf (1.4 MB)
As I understand your explenation the Kernel reads the information about color range from the EDID. If so how do you extract this information from the EDID when there is no explicit byte/bit for the color range? Maybe you can also reveal which byte of the EDID holds this information?
we are using the X11 windows system right now. I read the vmode variable with
Setting the color range in xorg.conf also changes the
FB_VMODE_LIMITED_RANGE bit accordingly (I assume
FB_VMODE_LIMITED_RANGE bit is 1 when limited range is active). After setting the color range to limited range the error is minimized to 1 (strange, because we are capturing in full range) but is still present in many gray levels.
After adjusting the
default_srgb_regamma_lut in nvdisp.c we were able to eliminiate some errors at the higher gray levels, but also added errors at the lower levels.
This was achieved by empirically changing the values of the
default_srgb_regamma_lut in nvdisp.c. Could someone provide information on how exactly this LUT works and what the values of this LUT represent?
Thanks in advance!
After modifying the Quantization Selectable (QS) flag in the VCDB section of the EDID, changing the color range was achieved using the GStreamer pipeline posted by @WayneWWW (see above).
Are you saying that you programmed and modified the content of your monitor EDID?
we are working with the Magewell USB Capture HDMI 4K Plus. This device has a Loop Through HDMI Port to supply a custom EDID. We connect this port with one of our devices which can be programmed with an arbitrary EDID (basically our device acts like a monitor).
No, that sRGB means nothing. You read the chromatcities from below that and then apply color managment according to that (not that anyone does that, LOL, except Chrome). Limited range vs full is signalled on a lower level if edid says that display supports selectable quantisation for RGB and separately for YCbCr/ICtCp. For YCbCr you cannot do full range on xvYCC, it is prohibited by the spec, display is mandated to not read the value. For sYCC and Adobe YCC you can do full range. Not that Nvidia is aware of that apparently, LOL!
thanks for the reply!
What do you mean with from below that?
You can see that info here Extended Display Identification Data - Wikipedia 10-bit 2° CIE 1931 xy coordinates for red, green, blue, and white point or in your pdf below. Again, that should have no effect on your case.
Alright. Thank you for clarification
The reference implementation of selectable quantisation is linux kernel and this edid-decode/parse-cta-block.cpp at 6514c9d9b18160fe9f09d3d70f99dda85d6fca71 · ValZapod/edid-decode · GitHub
Again, this happens NOT only in edid of your display, but IN THE SINK edid and its AVI Infoframes. So linux kernel is reference implementation of that.
Do you have any insights into setting the quantization range with X11 window system deactivated?
Maybe you could share those insights in this thread?
Anyhow, thank you for the information above!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.