Trying to use this hdmi display on my jetson nano:
for VR diy screen 2.9 inch 2k 1440*1440 display with MIPI HDMI interface LS029B3SX02|Tablet LCDs & Panels| - AliExpress
Display shows the boot-up sequence, but as soon as the Jetson logo appears, the display shuts off and the driver start blinking with blue led.
Doing xrandr through remote connection gives this result:
Screen 0: minimum 8 x 8, current 1440 x 1440, maximum 16384 x 16384
HDMI-0 connected primary 1440x1440+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1440x1440 90.01*+
640x350 85.08
DP-0 disconnected (normal left inverted right x axis y axis)
Setting to 640x350 resolution doesn’t solve the issue.
The display itself works with regular PC.
What do?
dmesg and xorg.0.log dump:
I see you had ModeDebug on, which is excellent! Take a look at this mode:
[ 8.336] (II) NVIDIA(GPU-0): Mode "1440x1440_90" is valid.
…this should work.
Other modes work as well, e.g.:
[ 8.336] (II) NVIDIA(GPU-0): Mode "640x350_85" is valid.
The above assumes you also follow the set scan rate.
It is possible that something like an energy saver mode could get in the way. One thing to test is that once it fails to simply unplug it and replug it. Or else boot without the monitor, and then plug in the monitor after boot is complete. Does any of this change things?
There doesn’t seem to be an energy saver mode.
Unplugging and replugging doesn’t do anything.
If I plug the hdmi connection to my laptop instead, the display works fine, in it’s native 1440x1440 resolution as well, so power doesn’t seem to be the issue. Booting headless first and then plugging in doesn’t do anything either.
The only time the display shows anything is during bootup, I can see the nvidia logo just before it shuts off.
Low power modes are generally there even if you don’t know it. However, since unplug and replug does not help I would say that it isn’t a low power mode getting in the way.
I’m going to suggest one more shorter log: Unplug the monitor, run “dmesg --follow” in one terminal, and run “tail -f /var/log/Xorg.0.log” in another terminal. Note where the logs end. Then plug in the monitor. Post the part of the logs which occurs upon plugin.
I noticed that the refresh rate when plugged into my win10 pc is 89.998hz. Could this be a hint?
When I put in an sd card with a new jetson nano image, the display works during the installation phase flawlessly.
I can set my region and user, but when it reboots to log into the system, the same old error occurs.
Just saw your log. You do have some valid modes available, so one of those should be picked. What Windows uses is irrelevant since that is just one possible mode of many, and at least some modes work. I suppose if you were trying to force a mode which was not accepted in the mode pool, then it would be a problem, but I don’t see that happening.
I still suggest monitoring “dmesg --follow” (perhaps via ssh login or serial console), and posting what shows up as the monitor is “hot plugged” (the cable unplugged and replugged). Similar, monitor “sudo tail -f /var/log/Xorg.0.log”, and see what shows up as new logging as you unplug and replug the monitor.
That is the initial log of X starting, and includes building the mode pool. This is valuable, but it does not include the changes which show up upon hot plug. The “dmesg --follow” command monitors kernel messages, and it is of interest what happens when you plug in the HDMI (or unplug/replug). This is part of the original log, but messages specific to the plug in event are important, and this is missing the way it has been shown.
The log for Xorg.0.log is similar, in that we know what happened when the server started, and it shows it should work, but I want to know what happens upon hot plug…this would be specific to the monitor’s physical plug-in, and we don’t know yet what happens upon hot plug in the Xorg.0.log. The command “tail -f /var/log/Xorg.0.log” will show you live updates of what is appended to the log during an unplug/replug event.
This is what happens in dmesg:
[[ 165.022579] Reserved SVD code 0[ 165.025744] Reserved SVD code 0 165.0 - Pastebin.com
This is what happens in Xorg.0.log:
[ 443.866] (–) NVIDIA(GPU-0): LZT YongXing (DFP-0): connected
[ 443.866] (–) NVIDIA(GPU-0): LZT YongXing (DFP-0): External TMDS
[ 443.874] (II) NVIDIA(0): Setting mode “HDMI-0: nvidia-auto-select @1440x1440 +0+0 {ViewPortIn=1440x1440, ViewPortOut=1440x1440+0+0}”
[ 443.937] (II) NVIDIA(0): Setting mode “HDMI-0: nvidia-auto-select @1440x1440 +0+0 {ViewPortIn=1440x1440, ViewPortOut=1440x1440+0+0}”
I don’t know what the “Reserved SVD code 0” is. Someone else will need to look that up, but I have not seen this before.
The Xorg.0.log basically says that it worked, and did not fail. Obviously something failed, but the software probably does not know it failed. Very odd.
I will say the resolution of “@1440x1440” is unusual. I am surprised the EDID supports this, and yet the Xorg log says it is a valid mode. Can you say anything more about this monitor? It seems unusual, and it should be working, but I suspect there hasn’t been anyone using this resolution before on a Jetson.
Also, if you either ssh in, or use a text console, or use a serial console, what do you see from this:
DISPLAY=:0 xrandr
…mostly I’m curious if the 640x350_85 shows up. If it does, then we could try using xrandr to put it in this other mode. It is hard to imagine a screen so large and oddly shaped that it supports 1440x1440 and also supports 640x350, but if just one mode can work, then it is progress and a clue (incidentally, what mode do you want this to be in?).
DISPLAY=:0 xrandr gives this result:
Screen 0: minimum 8 x 8, current 1440 x 1440, maximum 16384 x 16384
HDMI-0 connected primary 1440x1440+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1440x1440 90.01*+
640x350 85.08
DP-0 disconnected (normal left inverted right x axis y axis)
I’ve tried this other mode before, it doesn’t work either.
The display should definitely work hardware-wise, because as I mentioned, I can complete the initial graphic OS setup with the display, but as soon as it logs into the system, display doesn’t work anymore. Seems maybe like some software conflict issue.
The display info is in the aliexpress link in OP, it’s a small 5.5 inch high resolution display for VR/AR applications.
I got the display to work with raspberry pi 3B in a weird workaround way. Had a similar issue where it just simply won’t start up the display. For some reason it displays only if I hook up another regular large monitor during bootup, and then switch the connection with the small display when the system is already logged in. It then fires up the display in the same aspect ratio as my large monitor.
The same workaround unfortunately does not work for jetson nano.
Is this display stereo? A pair of 1440x720 combined to create 1440x1440 might make more sense in such a display, but it might be listed with just the 1440x1440.
I don’t think the original o/s setup completely relies on EDID, but it might. If not, then I would think the o/s setup would work until it needs to actually run an X server (it is the X server which I think demands EDID).
Not having the monitor work, but connecting another monitor to make it work, implies that the mode which works when another monitor is attached is not correctly set up in EDID, but the other monitor which makes it work would make that EDID mode work. Then the non-working monitor would work in that mode despite not having achieved this with its own EDID. Basically it can cause the mode of another monitor to be inherited.
I am curious, if you log in with ssh/serial console/regular console, what happens if you do this:
DISPLAY=:0 xrandr --output HDMI-0 --mode 640x350 --rate 85.08
Sorry for late reply.
I am wondering this statement “The display should definitely work hardware-wise, because as I mentioned, I can complete the initial graphic OS setup with the display, but as soon as it logs into the system, display doesn’t work anymore.”
Actually, there is no difference between “doing user configuration” and “after the user configuration”. They are all in linux kernel stage.
Can you please try below usecase and share the dmesg for each case?
-
Boot up the device without any monitor connected. Hotplug the monitor after few second that you are sure the device is up.
-
Boot up the device with the monitor connected from the beginning.
BTW, somehow my network blocks the pastebin. Can you just attach two text file on the forum? We support upload files/ images here.
It’s a single 1440x1440 display, it’s square shaped.
I have attached entire dmesg logs for hotplugged and always connected scenarios.
always.txt (56.2 KB)
hotplug.txt (56.1 KB)
I don’t see any error log from kernel. Only the “Reserved SVD code 0” looks suspicious. I will check this later.
Can you also dump me the clock tree from /sys/kernel/debug/clk/clock_tree? You have to use sudo here.
Actually I don’t have tegra device now so the path is uncertain. If you cannot find clock_tree there, please just use find command to find “tree” under /sys/kernel/debug. It shall give you where to find the clock tree.
I’d say basically the same thing as what @WayneWWW just said. The dmesg log does not show any error, although the SVD code thing is odd (and I don’t know what this is for).
Note: The clock_tree can be via “sudo cat /sys/kernel/debug/clk/clock_tree”. Or to a file, “sudo cat /sys/kernel/debug/clk/clock_tree | tee clock_tree.txt”
One thing that is still missing: Monitor “sudo tail -f /var/log/Xorg.0.log”, and post what shows up upon unplug/replug of the monitor (you don’t need the whole Xorg.0.log since what is important is what happens upon unplug and replug events).
1 Like
There is no clock_tree file in clk, and I cannot find it in debug, file manager search function does not find it.
The same thing happens in Xorg.0.log as before, it sets mode to “NULL” if I had another monitor connected previously, before it auto-selects to 1440x1440.
I noticed that the HDMI timings on the nvidia control panel on my PC is 1440 50 8 1514 1440 8 2 1456.
But verbose xrandr on jetson nano shows that they’re 1440 50 8 1513 1440 8 2 1456.
The total horizontal pixel count is off by 1, could this cause the issue?
How could I change HDMI timings on the jetson so I could test it out?
I noticed after troubleshooting for hours that making new xrandr modes is disabled on the jetson.
Each file in “/sys” is the product of a driver or kernel feature. The content does not actually exist on disk. Instead, the content is in RAM from something such as a kernel driver pretending this is a file. So the lack of this could be a number of things. Possibilities:
- The current model of hardware and release don’t use this.
- A kernel driver or feature was left out when building a custom kernel.
-
- Subset: A kernel module was installed to the wrong location because “
uname -r” changed.
-
- Subset: Device tree changed and the driver cannot find the hardware and so does not load.
-
- Subset: Device is there and found, but shuts down, e.g., because a power rail turns off.
I do have to say that “1440x1440” is an odd resolution. I’m guessing this resolution has not actually been tested on hardware before, so maybe there is some sort of fluke of a problem even though the EDID says it can work. You mentioned a question about horizontal pixel count being off by 1, and I don’t know if this is a problem or not, but perhaps it is a problem but nobody has run into it before.