override EDID data to connect to HDMI display

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Hello, I am trying to get the Jetson Nano to work with a small HDMI display, but when connected to the jetson’s HDMI port nothing is displayed. both the settings menu and xrandr claim the display only supports 640x480, although it is a 2560x1440 display, and the same display works fine when connected to other computers.

According to other threads on this forum, the jetson driver blocks any attempt to create a custom resolution with xrandr and will only output resolutions supported by the monitor’s EDID data. Is there any possible way to override this behavior, or give the OS a different EDID to read from instead of the one from the display? I need to get this specific display working with the jetson because it is part of an embedded project i am working on and I have no other options.

Here is the display’s raw EDID hex data and the output of edid-decode:

00 ff ff ff ff ff ff 00 33 54 01 00 00 00 00 00
0c 1b 01 03 80 00 00 78 0a 07 f5 9a 56 4e 86 26
1e 50 54 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 ff 4f a0 96 50 00 10 a0 46 23
c2 00 5a a0 00 00 00 18 00 00 00 fc 00 4c 53 30
36 30 52 31 53 58 30 31 20 20 00 00 00 ff 00 30
30 30 30 30 30 30 30 20 20 20 20 20 00 00 00 fd
00 17 4b 0f f0 1e 00 0a 20 20 20 20 20 20 01 82
02 03 17 74 47 00 00 00 00 00 00 00 23 09 7f 07
66 03 0c 00 30 00 80 ff 4f a0 96 50 00 10 a0 46
23 c2 00 5a a0 00 00 00 18 ff 4f a0 96 50 00 10
a0 46 23 c2 00 5a a0 00 00 00 18 ff 4f a0 96 50
00 10 a0 46 23 c2 00 5a a0 00 00 00 18 ff 4f a0
96 50 00 10 a0 46 23 c2 00 5a a0 00 00 00 18 ff
4f a0 96 50 00 10 a0 46 23 c2 00 5a a0 00 00 00
18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8d

Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   33 54 01 00 00 00 00 00 0c 1b
version:         01 03
basic params:    80 00 00 78 0a
chroma info:     07 f5 9a 56 4e 86 26 1e 50 54
established:     00 00 00
standard:        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 1:    ff 4f a0 96 50 00 10 a0 46 23 c2 00 5a a0 00 00 00 18
descriptor 2:    00 00 00 fc 00 4c 53 30 36 30 52 31 53 58 30 31 20 20
descriptor 3:    00 00 00 ff 00 30 30 30 30 30 30 30 30 20 20 20 20 20
descriptor 4:    00 00 00 fd 00 17 4b 0f f0 1e 00 0a 20 20 20 20 20 20
extensions:      01
checksum:        82

Manufacturer: LZT Model 1 Serial Number 0
Made week 12 of 2017
EDID version: 1.3
Digital display
Image size is variable
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
Detailed mode: Clock 204.790 MHz, 90 mm x 160 mm
               1440 1510 1545 1590 hborder 0
               2560 2572 2574 2576 vborder 0
               -hsync -vsync 
Serial number: 00000000
Monitor ranges (GTF): 23-75Hz V, 15-240kHz H, max dotclock 300MHz
Has 1 extension blocks
Checksum: 0x82 (valid)

CEA extension block
Extension version: 3
19 bytes of CEA data
  Video data block
  Audio data block
    Linear PCM, max channels 2
    Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
    Supported sample sizes (bits): 24 20 16
  Vendor-specific data block, OUI 000c03 (HDMI)
    Source physical address 3.0.0.0
    Supports_AI
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
4 native detailed modes
Detailed mode: Clock 204.790 MHz, 90 mm x 160 mm
               1440 1510 1545 1590 hborder 0
               2560 2572 2574 2576 vborder 0
               -hsync -vsync 
Detailed mode: Clock 204.790 MHz, 90 mm x 160 mm
               1440 1510 1545 1590 hborder 0
               2560 2572 2574 2576 vborder 0
               -hsync -vsync 
Detailed mode: Clock 204.790 MHz, 90 mm x 160 mm
               1440 1510 1545 1590 hborder 0
               2560 2572 2574 2576 vborder 0
               -hsync -vsync 
Detailed mode: Clock 204.790 MHz, 90 mm x 160 mm
               1440 1510 1545 1590 hborder 0
               2560 2572 2574 2576 vborder 0
               -hsync -vsync 
Detailed mode: Clock 204.790 MHz, 90 mm x 160 mm
               1440 1510 1545 1590 hborder 0
               2560 2572 2574 2576 vborder 0
               -hsync -vsync 
Checksum: 0x8d (valid)

EDID block does NOT conform to EDID 1.3!
	Name descriptor not terminated with a newline
	Detailed block string not properly terminated
2

I tried medium hard to override the EDID of the Tegra NVIDIA driver about a year ago, and didn’t manage to do so.
So, no, I would guess not?

3

I had read somewhere this forum that L4T kernel has a feature embedded an customized EDID data into dtb blob.

4

You could either add edid inside hdmi-display or just enable the use_fallback in edid.c in kernel driver.

https://elinux.org/Jetson_TX2/r28_Display_debug

5

Is there any more specific tutorial on how to do those things? I don’t know where those files are

6

Please download the kernel source from download center. Follow the tutorial on L4T document to build the kernel.

7

If you’ve flashed from Linux with SDK Manager you will have a “Linux_for_Tegra/” subdirectory. Within this will be the script “source_sync.sh”. One way of downloading the kernel source (both in and out of tree content) for release R32.1:

./source_sync.sh -k tegra-l4t-r32.1

…the “sources/” subdirectory will contain the content. Within “sources/” the “edid.c” file is at:

./kernel/nvidia/drivers/video/tegra/dc/edid.c

Before you update the kernel you might save a copy of the existing configuration on the running Nano. Save a copy of “/proc/config.gz”. Once CONFIG_LOCALVERSION of this is edited to become “-tegra” that file is an exact match to the running system’s configuration. You’ll use the same configuration after making the edit. FYI, config.gz can be uncompressed, “gunzip config.gz”. This can be edited, and a copy added to the top level kernel source directory (placed in “kernel/kernel-4.9/” as name “.config”) before starting the kernel build.

Note: In some cases changing the base kernel code would imply wanting to change CONFIG_LOCALVERSION slightly. Probably it is ok in this case, and reusing the old modules should be fine as long as the code is not being put in a module. The kernel loads modules at “/lib/modules/$(uname -r)/”, and the suffix is what the CONFIG_LOCALVERSION is. If you change the base Image too much, then you’d change the CONFIG_LOCALVERSION, and as a consequence you’d also need to rebuild all of the modules and place them in the new location since “uname -r” would change. The old kernel could be left in place as alternate boot items to be selected by serial console during boot.

8

hello,did you solve this problem?