1440 x 2560 HDMI monitor on Xavier NX not working

Dear all, I am working on a stereoscopic vision system based on a Xavier NX. The system uses a 5.5 inches LCD 1440x2560@50Hz (yes, the screen ratio is 9:16). The screen works correctly in Windows and Linux on x64 architecture. It also works on Tegra TX2 with Jetpack 3.3. Whereas on Tegra TX2 with Jetpack 4.x and on Xavier N X development kit it does not work.
X works correctly but it configures the LCD with a resolution of 640x350@85Hz and the LCD stays black, however I can use VNC to access the desktop and xrandr says that the only available resolution for the screen is 640x350@85Hz.

I cannot get the EDID with sudo get-edid, as I get:

This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 1
No EDID on bus 2
No EDID on bus 3
No EDID on bus 4
Permission denied opening i2c. Run as root!
I’m sorry nothing was successful. Maybe try some other arguments
if you played with them, or send an email to Matthew Kern pyrophobicman@gmail.com.

I can, however, find the EDID in /sys/kernel/debug/tegradc.0/edid. The content is attached and is not conformant: the final lines of edid-decode output are:

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

I created a correct EDID (attached) and I used it to fill in default_720p_edid[256] and I set use_fallback to true. The result after flashing is the same (I added some pr_warn in edid.c code to make sure that the fallback edid is used).

For completeness, if I connect the LCD to a Tegra TX2 flashed with Jetpack 3.3 I got a similar behavior, as X configure the LCD with a resolution of 640x350@85, but on that platform I can change the resolution to 1440x2560@50 with xrandr.

I would like to know if it is possible to use a resolution of 1440x2560@50Hz on Jetson NX and in case how I can force it. I would also be interested in understanding why Jetpack 4 on Tegra TX2 does not support that LCD while Jetpack 3.3 supports I think this may help me in solving the problem.

Thanks in advance,

edid_correct.bin (256 Bytes)
edid_original.bin (256 Bytes)
Console_log.txt (27.4 KB)
Xorg.0.log (205.9 KB)

  1. Share us the dmesg first.

  2. Custom carrier board or devkit?

  3. In your attachment, do you ever connect the hdmi cable?

Dear WayneWWW, thanks for your feedback. I am working on the Xavier NX devkit. When I collected the log files the cable was connected before powering on the system.

I re-flashed the system with a clean image and I repeated the test (i.e. connected the LCD to the devkit with a working HDMI cable and powered the devkit on). I attach the console log, the output of dmesg and Xorg.0.log relative to this test.

Thanks again,

console_log.txt (27.8 KB)
dmesg.txt (69.1 KB)
Xorg_0_log.txt (14.8 KB)


The kernel itself does not provide fatal error. But we have few things to try here.

  1. Could you enable mode debug in xorg so that we can see more log from Xorg log?

#Add below option in /etc/X11/xorg.conf, ‘Section “Device”’. Verbose mode logging will be shown in /var/log/Xorg.0.log
Section “Device”

Option “ModeDebug”


  1. Will you see this issue if you “hotplug” the cable after the device is booting up? I mean you don’t connect the hdmi cable until the device fully boots up.

  2. I guess this issue only happens to this specific monitor, could you confirm?

  3. Could you share me the edid as a text file? I cannot open the bin file you shared.

Dear WayneWWW,

  1. I attach the three files collected after enabling mode debug in xorg.conf
    console_hdmi_connected.txt (27.8 KB)
    dmesg_hdmi_connected.txt (66.2 KB)
    Xorg_0_log_hdmi_connected.txt (201.6 KB)

  2. I attach the three files collected after a test in which I powered on the devkit without any connected screen and then I connected the faulty LCD after the boot completed
    console_hdmi_hotplug.txt (27.9 KB)
    dmesg_hdmi_hotplug.txt (65.2 KB)
    Xorg_0_log_hdmi_hotplug.txt (202.2 KB)

3 I confirm you that “standard” monitors work correctly

4 Please find the edid file in txt format attached
edid.txt (784 Bytes)


Hi Davide,

Some observations

  1. Xorg.0.log does not receive any mode 1440x2560 from display kernel. It means this mode is filtered out from kernel
  2. I am not sure why I can only see one mode from your edid if I give this edid to edid parser. It means if this mode 1440x2560 is being rejected by driver, it would cause unpredictable behavior.

My suggestion is

If you want to find out why the kernel driver filters out your mode, you can add some print in the mode filter function in hdmi2.0.c.

After that, you could compare the code and see why jetpack3.x does not filter this out.

But when kernel rejects some modes, it probably means hardware may not fully support such mode. Since jetpack4.x are latest release than 3.x, I would say jetpack3.x may work only because we didn’t fix some bugs at that time.

Thanks WayneWWW: I will try understanding why the mode is filtered out on Jetpack 4 and not on Jetpack 3.

I will post here any update.


Dear WayneWWW,

thanks to your hints I had a look at the file kernel/nvidia/drivers/video/tegra/dc/hdmi2.0.c and I found the lines

if (mode->xres > 4096 || mode->yres > 2160)
return false

in the function tegra_hdmi_fb_mode_filter. I edited the first one to:

if (mode->xres > 4096 || mode->yres > 2560)

Then I recompiled and flashed the kernel and the screen started working seamlessly. Since I never had any problem with Tegra TX2 with Jetpack 3.3 and this LCD screen I consider quite safe to go on with this workaround.

Thanks again for your support.

1 Like

Hi @davide.zerbato,

I also want to know what kind of monitor is that?

Is it a native HDMI port monitor? or any adapters are applied?

Hi @WayneWWW,

there are no adapters: it is an LCD that is usually sold as a (spare) part for 3D printers. It comes with its own HDMI controller. We use it as it provides good resolution in a 5.5 inches format.