1440x2560 HDMI display not working

Hello, I am trying to get the Jetson Nano working with a smartphone LCD screen connected to an HDMI driver board. Since the display is designed for smartphones, its resolution is 1440x2560 (taller than it is wide) rather than the common desktop resolution of 2560x1440. However, when I connect it to the jetson’s HDMI port, it is detected as 640x480 and nothing is displayed at all.

I am able to reprogram the HDMI driver board, and when i programmed it to accept 2560x1440, the jetson detected the correct resolution and displayed to it just fine. However, since the LCD panel is not designed for this resolution, the image is jumbled up and unusable.

Because everything is identical in both cases other than the resolution, it seems like the jetson is not accepting the resolution of 1440x2560 for some reason. Is there any way to get the jetson to work with this type of screen?

Bump

Hi colec518,

In official support, we only allow the CEA mode. Such mode like 1440x2560 may be filtered out by the hdmi driver.

A workaround here is to comment out below line in “tegra_hdmi_fb_mode_filter” in hdmi2.0.c and rebuild the kernel.

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

Jetson Nano is small embedded system, so it makes sense to use small screens with it. Anyway, the line of code clearly does not check if the mode is CEA or not, it just limits yres to 2160 for no apparent reason. But it gets in the way when trying to use high quality small screens with 2.5K or 4K resolution.

Please consider fixing this. Recompiling the kernel just to make a screen work is annoying, and also it makes Jetson Nano less accessible or more inconvenient to users who interested in using it with high resolution small screens. I think recompiling the kernel should not be necessary to just fix known broken hardcoded value to get a screen working if it happens to have native 2.5K / 4K portrait resolution.

I can confirm that removing the line (or replacing “2160” with “4096” in it) fixes the issue but I think it would be better if this worked out-of-the-box.

1 Like

I completely agree. There is a huge supply of these small high-res displays now. They make perfect displays for AR/VR and other HMD/portable system R&D. I am sure I speak for a lot of people when I say that I am TIRED of using low-res displays with systems as capable as these, seems like a waste. That being said, I’d still like to know why 1440p was filtered. I trust NVIDIA Engineering had a reason

Also:

After editing “hdmi2.0.c” to remove the filtering for yres > 2160 (I used 4096 as well), and then recompiling the kernel, I was able to use my 1440x2560 MIPI display. Presently, using the following xrandr commands, this produces the desired output (after rebooting with the new kernel build):

xrandr --output HDMI-0 --mode 1440x2560 --rotate right

Granted, I now need to make some changes so I boot into that resolution when needed, but that should be an academic exercise. The proof of concept is solid.

Also, the website below has an awesome step-by-step on how to rebuild the kernel. I was able to do so on the Nano w/ no cross-compile. You only need a little over an hour to do this. Make sure you check for the (latest) correct version of the kernel you are grabbing:

[NVIDIA Jetson Nano - Docker optimized Linux Kernel · Docker Pirates ARMed with explosive stuff](Build Jetson Nano Kernel Locally)

FYI: I acquired the display from Amazon…a 5.5" unit with HDMI->MIPI adapter.

Hope these notes help out!

1 Like

Hello,

For the reason that this is getting filter out.
The filtering logic is based on the HDMI 2.0 spec and CEA 861-F spec where vactive doesn’t exceed 2160.

There were some modes that crashed the system if we don’t filter them out. Thus ,we added this years ago to comply the spec.

The problem is, many LCDs have vertical and horizontal axes swapped, and this is typical for most small screens. And small screens are especially relevant to platforms such as Jetson Nano.

If the intention is to limit resolution to 4K, perhaps the check could be changed like this:
if ((mode->xres > 4096 || mode->yres > 2160) && (mode->xres > 2160 || mode->yres > 4096))
Then modes beyond 4K which can crash the system (I guess something like 3840x2560 or higher) will be filtered out but both landscape and portrait LCDs with 2.5K and 4K resolution will work out-of-the-box.

As it is now, it’s strange to see 3840x2160, 2560x1440 and even 1080x1920 supported but not 1440x2560 and 2160x3840. Especially considering the fact it is possible to use 3840x2160 in portrait mode with Jetson Nano, or 1440x2560 in landscape mode, etc. As far as I can tell, only noticeable difference between portrait and landscape LCD is default orientation, but it can be easily changed (for example, by putting something like sleep 5; DISPLAY=:0 xrandr --output HDMI-0 --rotate left in ~/.xprofile). And for some projects, LCD with native portrait orientation may be a perfect fit.

By the way, I googled CEA 861-F and it is labeled as “DTV Profile For Uncompressed High Speed Digital Interfaces”. For DTV screens which as far as I know always use landscape orientation, it makes sense to talk about vertical 2160 limit. But this does not apply to mobile and embedded platforms which can have either portrait or landscape screens. Hence the suggestion above, still use 2160 limit, but in a way that will work for both landscape and portrait LCDs, this would make Jetson Nano much more user-friendly. Besides, many projects would work just fine with stock kernel, so not everybody needs or wants to learn compiling and patching the kernel, especially right after they purchased Jetson Nano and LCD for it and trying to get started. Don’t get me wrong, I think that Jetson Nano is great, but it could be even better if some small but annoying issues such as this are fixed. So please consider my suggestion above, or something equivalent, to allow using 2.5K and 4K portrait LCDs out-of-the-box.

Hi,

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

Not sure if there is a typo in your logic here. This seems block xres>2160 and yres>2160.

1 Like

Yes, it’s a typo. It should have been:

if ((mode->xres > 4096 || mode->yres > 2160) && (mode->xres > 2160 || mode->yres > 4096))

1 Like

@WayneWWW: Thanks for clarifying the reason for the filtering. As suspected there was a logical reason behind that decision.

As @Lissanro has pointed out it appears a need to filter for both portrait and landscape modes exists. It seems the logic you both discussed is correct…will likely give it a try. At any rate, this thread has saved me a lot of time and I appreciate the insight from everyone.

FYI: Wanted to clarify my display is a native portrait-mode 1440x2560. However, for my project I desire a landscape mode, hence my comments above about “rotating” the image via xrandr.