How to get dual 1440*1440 VR display to work

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Hello everyone,

I am new to the nano, so please be patient with me, but I have been having problems with wisecoco’s 90hz 14401440 dual vr display. The product is a mipi based display but it comes with an hdmi driver board that also powers it, and has two buttons that switch between split screen and one whole screen split between the two displays. When I boot the nano with the display attached, the logo and some startup text will be displayed on one of them. However, after boot they remain black and unresponsive. Running XRANDR shows that a 28801440 (makes sense because it’s two side by side 1440*1440) display is connected at HDMI zero. In extlinux.conf I set the resolution to this, but still nothing changed. This display module was expensive, what can I do?

3

Is this a question for Jetson Nano or Jetson Orin Nano? These two are totally different so better checking it first.

4

Sorry, I am using the jetson nano B01 by yahboom. I am using jetpack 4.6.1 without any of the advanced options installed from SDK manager(just the raw OS).

5

Unfortunately, I don’t think Jetson nano is able to output such resolution.

6

That is unfortunate, but is the nano capable in general of driving a hdmi driver board with dual mipi displays attached? Is there no possible way the nano can output that resolution, and if not what other vr displays or resolutions can be used with the nano? Also, doesn’t the nano support up to 4K output, why wouldn’t 2880x1440 be accepted?

7

IMG_4961
IMG_49613024×4032 1.77 MB

Additionally, I reflashed the eMMC 16 gb with the OS and as you can see the display was driven perfectly during installation phase. As soon as installation is complete the display goes dark.

8

Most GPUs are discrete GPUs (dGPU) sitting a PCI bus. The Jetson GPU is an integrated GPU (iGPU) which is attached directly to the memory controller. For the iGPU any “detection” software requiring a PCI query will typically not work as expected (unimportant for this use), which means the driver for the iGPU is also different than the mainstream PCI drivers.

HDMI and DisplayPort monitors have a method to query the monitor for what its capabilities are (the EDID). Most GPUs can be told to configure via EDID (automatic) or manually (something a user says to use despite EDID modes available). The Jetson iGPU only allows EDID configuration (although it does have a fallback mode).

If your VR display does not provide EDID, then this is one reason why it would fail. However, you can tell the driver to log whatever EDID modes it sees, and to comment on whether it is an accepted or rejected mode. You would go to “/etc/X11/xorg.conf”, and find the section for “Device” and add the Option "ModeDebug":

Section "Device"
    Option "ModeDebug"

Every X11 display has a “context” which is stored in the environment variable “DISPLAY”. Normally it is “:0”. This is used to number logs. If your DISPLAY is for 0, then then log is:
/var/log/Xorg.0.log

Stereo has two monitors (depending on how they are used together), and so VR goggles might have two contexts, e.g., maybe it is “:0” and “:1”. If this is the case, then you’d have two logs, Xorg.0.log and Xorg.1.log. You could look at those logs and search for “ModePool” to see the full list of acceptable modes. Prior to that each individual EDID mode the monitor provides will be commented on as to whether the mode is accepted or rejected.

9

Xorg.0.log (3.0 MB)
Xorg.1.log (228.7 KB)
These are my Xorg logs after rebooting and having the VR display attached. To check the logs afterwards I plugged in my 1024x600 functioning display, so that is why that display is recongnized in the logs. It appears in both logs my VR device has two modes, 2880x1440 and 640x350, and EDID is provided for both. I am not quite sure how to interpret the logs however, can you look and tell me if either of them denote how to fix this display? Also, why is one log so much shorter than the other shouldn’t both VR logs be of equal length?

10

Some questions summarized at the end.

Just to verify that both logs are correct, when you start video on the VR goggles, are the timestamps the same for both the Xorg.0.log and the Xorg.1.log? Use:
ls -ltr /var/log/Xorg.0.log /var/log/Xorg.1.log
(they’ll be almost the exact same timestap or exact; if Xorg.1.log was from an earlier run, then it will be significantly older)

Incidentally, is this VR “LZT YongXing”? If so, then this is the ModePool for it.

I will copy and paste the relevant excerpts from the “ModePool” section of valid modes of the “:0” context (which is unusually long; it appears that one log has two ModePool sections, and thus the reason why I am asking to verify matching timestamps on the logs):

[     5.654] (II) NVIDIA(GPU-0): --- Modes in ModePool for LZT YongXing (DFP-0) ---
[     5.654] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[     5.654] (II) NVIDIA(GPU-0): "2880x1440"          : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[     5.654] (II) NVIDIA(GPU-0): "2880x1440_60"       : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[     5.654] (II) NVIDIA(GPU-0): "640x350"            :  640 x  350 @  85.1 Hz  (from: EDID)
[     5.654] (II) NVIDIA(GPU-0): "640x350_85"         :  640 x  350 @  85.1 Hz  (from: EDID)
[     5.654] (II) NVIDIA(GPU-0): --- End of ModePool for LZT YongXing (DFP-0): ---
...
[    10.408] (II) NVIDIA(GPU-0): --- Modes in ModePool for LZT YongXing (DFP-0) ---
[    10.408] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[    10.408] (II) NVIDIA(GPU-0): "2880x1440"          : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[    10.408] (II) NVIDIA(GPU-0): "2880x1440_60"       : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[    10.408] (II) NVIDIA(GPU-0): "640x350"            :  640 x  350 @  85.1 Hz  (from: EDID)
[    10.408] (II) NVIDIA(GPU-0): "640x350_85"         :  640 x  350 @  85.1 Hz  (from: EDID)
[    10.408] (II) NVIDIA(GPU-0): --- End of ModePool for LZT YongXing (DFP-0): ---
...

(it appears that this is repeated over and over in the log)

These are validated MetaModes; MetaModes are not an exact match, and might clip a small horizontal or vertical part of the input video, or perhaps stretch the video. Most people will use only the valid modes which are not MetaModes, but MetaModes are often useful:

[     5.654] (II) NVIDIA(0): Validated MetaModes:
[     5.654] (II) NVIDIA(0): Virtual screen size determined to be 2880 x 1440
[     5.654] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: 640x350"
[     5.654] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 2560 x 1440, ViewPortOut = 2560 x 1440 + 160 + 0 }"
[     5.655] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 1920 x 1200, ViewPortOut = 2304 x 1440 + 288 + 0 }"
[     5.655] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 1920 x 1080, ViewPortOut = 2560 x 1440 + 160 + 0 }"
[     5.656] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 1680 x 1050, ViewPortOut = 2304 x 1440 + 288 + 0 }"
[     5.656] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 1600 x 1200, ViewPortOut = 1920 x 1440 + 480 + 0 }"
[     5.657] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 1440 x 900, ViewPortOut = 2304 x 1440 + 288 + 0 }"
[     5.657] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 1366 x 768, ViewPortOut = 2561 x 1440 + 159 + 0 }"
[     5.657] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 1280 x 1024, ViewPortOut = 1800 x 1440 + 540 + 0 }"
[     5.658] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 1280 x 800, ViewPortOut = 2304 x 1440 + 288 + 0 }"
[     5.658] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 1280 x 720, ViewPortOut = 2560 x 1440 + 160 + 0 }"
[     5.658] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 1024 x 768, ViewPortOut = 1920 x 1440 + 480 + 0 }"
[     5.659] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 800 x 600, ViewPortOut = 1920 x 1440 + 480 + 0 }"
[     5.659] (II) NVIDIA(0): Adding implicit MetaMode: "HDMI-0: nvidia-auto-select { ViewPortIn = 640 x 480, ViewPortOut = 1920 x 1440 + 480 + 0 }"

The following though makes it questionable if the VR goggles have correct EDID responses:

[     5.659] (WW) NVIDIA(0): LZT YongXing (DFP-0) does not have an EDID, or its EDID does
[     5.659] (WW) NVIDIA(0):     not contain a maximum image size; cannot compute DPI from
[     5.659] (WW) NVIDIA(0):     LZT YongXing (DFP-0)'s EDID.
[     5.659] (==) NVIDIA(0): DPI set to (75, 75); computed from built-in default

What is the EYA eM513A?

I see this, and perhaps EYA eM513A is the regular monitor and not VR?

[    44.884] (II) NVIDIA(GPU-0): --- Modes in ModePool for EYA eM513A (DFP-0) ---
[    44.884] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 1024 x  600 @  59.8 Hz  (from: EDID, Detailed)
[    44.884] (II) NVIDIA(GPU-0): "1920x1080"          : 1920 x 1080 @  60.0 Hz  (from: EDID, CEA)
[    44.884] (II) NVIDIA(GPU-0): "1920x1080_60"       : 1920 x 1080 @  60.0 Hz  (from: EDID, CEA)
[    44.884] (II) NVIDIA(GPU-0): "1920x1080_60_0"     : 1920 x 1080 @  59.9 Hz  (from: EDID, CEA)
[    44.884] (II) NVIDIA(GPU-0): "1920x1080_50"       : 1920 x 1080 @  50.0 Hz  (from: EDID, CEA, Detailed)
[    44.884] (II) NVIDIA(GPU-0): "1920x1080_50_0"     : 1920 x 1080 @  50.0 Hz  (from: EDID, CEA)
[    44.884] (II) NVIDIA(GPU-0): "1280x1024"          : 1280 x 1024 @  75.0 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "1280x1024_75"       : 1280 x 1024 @  75.0 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "1280x720"           : 1280 x  720 @  60.0 Hz  (from: EDID, CEA)
[    44.885] (II) NVIDIA(GPU-0): "1280x720_60"        : 1280 x  720 @  60.0 Hz  (from: EDID, CEA)
[    44.885] (II) NVIDIA(GPU-0): "1280x720_60_0"      : 1280 x  720 @  59.9 Hz  (from: EDID, CEA)
[    44.885] (II) NVIDIA(GPU-0): "1280x720_50"        : 1280 x  720 @  50.0 Hz  (from: EDID, CEA, Detailed)
[    44.885] (II) NVIDIA(GPU-0): "1280x720_50_0"      : 1280 x  720 @  50.0 Hz  (from: EDID, CEA)
[    44.885] (II) NVIDIA(GPU-0): "1024x768"           : 1024 x  768 @  75.0 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "1024x768_75"        : 1024 x  768 @  75.0 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "1024x768_70"        : 1024 x  768 @  70.1 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "1024x768_60"        : 1024 x  768 @  60.0 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "1024x600"           : 1024 x  600 @  59.8 Hz  (from: EDID, Detailed)
[    44.885] (II) NVIDIA(GPU-0): "1024x600_60"        : 1024 x  600 @  59.8 Hz  (from: EDID, Detailed)
[    44.885] (II) NVIDIA(GPU-0): "832x624"            :  832 x  624 @  75.0 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "832x624_75"         :  832 x  624 @  75.0 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "800x600"            :  800 x  600 @  75.0 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "800x600_75"         :  800 x  600 @  75.0 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "800x600_72"         :  800 x  600 @  72.2 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "800x600_60"         :  800 x  600 @  60.3 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "800x600_56"         :  800 x  600 @  56.3 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "720x576"            :  720 x  576 @  50.0 Hz  (from: EDID, CEA, Detailed)
[    44.885] (II) NVIDIA(GPU-0): "720x576_50"         :  720 x  576 @  50.0 Hz  (from: EDID, CEA, Detailed)
[    44.885] (II) NVIDIA(GPU-0): "720x576_50_0"       :  720 x  576 @  50.0 Hz  (from: EDID, CEA)
[    44.885] (II) NVIDIA(GPU-0): "720x480"            :  720 x  480 @  59.9 Hz  (from: EDID, CEA)
[    44.885] (II) NVIDIA(GPU-0): "720x480_60"         :  720 x  480 @  59.9 Hz  (from: EDID, CEA)
[    44.885] (II) NVIDIA(GPU-0): "720x400"            :  720 x  400 @  70.0 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "720x400_70"         :  720 x  400 @  70.0 Hz  (from: EDID)
[    44.885] (II) NVIDIA(GPU-0): "640x480"            :  640 x  480 @  75.0 Hz  (from: EDID)
[    44.886] (II) NVIDIA(GPU-0): "640x480_75"         :  640 x  480 @  75.0 Hz  (from: EDID)
[    44.886] (II) NVIDIA(GPU-0): "640x480_73"         :  640 x  480 @  72.8 Hz  (from: EDID)
[    44.886] (II) NVIDIA(GPU-0): "640x480_60"         :  640 x  480 @  59.9 Hz  (from: EDID, CEA)
[    44.886] (II) NVIDIA(GPU-0): --- End of ModePool for EYA eM513A (DFP-0): ---

These questions summarized:

  • Which monitor is EYA eM513A? (I’m guessing an ordinary monitor)
  • Which monitor is LZT YongXing? (I’m guessing it is the VR)
  • Do the timestamps of the Xorg.0.log and Xorg.1.log match? Or is one significantly older in time than the other? If similar, they are from the same session logging two contexts; if different, then the older one is probably irrelevant.
  • Note: The Xorg.1.log is much shorter, and is only for EYA eM513A. I suspect the logs are unrelated to the VR.
11

The EYA monitor is my 1024*600 working monitor. The LZT is my VR monitor. I repeated my process of rebooting with the VR monitor and checked the time stamps, they were both at the same time. With this information, what do the logs suggest I can do to cause my VR displays to function property instead of saying black?

12

Looks like this might be slightly complicated due to multiple listings of the VR goggles and regular monitor. I’m going to have you acquire the log files for purely VR to be sure there is no confusion. I’ll explain below, but basically you will want any “Xorg.*.log” which occurs as a result of having only the VR goggles installed (this might be an “Xorg.0.log” and “Xorg.1.log” again, but it might be just a single log since the regular monitor will not be connected). I just need to make sure that the log is (A) entirely related to the VR and not duplicated due to (B) removing and adding the VR resulting in copies of log lines.

Since the VR monitor had its stats repeated I’m not sure if that was due to having stereo capability or if that is because the monitor was unplugged and replugged. The best log would be from having just the VR headset plugged for the entire boot. I will explain how to get that log.

If you look at “ls -ltr” by itself, then what you will see is a time sorted list of files, e.g., “ls -ltr /var/log/Xorg.*.log” will show the most recent log at the bottom of the terminal. If you expand this to “Xorg.*.log*” (notice there are now two “*” characters, not one), then it will give you a time sorted list of all current and older logs for Xorg on all contexts. Start by deleting all of the previous “old” logs (they will have names like “Xorg.0.log.old”). Those logs are from your previous boot. If you were to now reboot, then the logs which are currently “new” will become “.log.old”. With all of the “Xorg.*.log.old” files removed before reboot you can be certain that after reboot the logs of the session you were in are now the “.old” logs on this new boot. If you were to remove all “.old” Xorg logs now, shut down, put only the AR goggles onto the Jetson, and boot, then what you have in the current “Xorg.*.log” will be for the goggles, and there will be only one copy since you are not unplugging and replugging the VR goggles. You wouldn’t be able to see anything, but you now have two methods to get those logs:

  • You could log in via either serial console or ssh and copy the log somewhere before rebooting or before adding the regular monitor. Just be sure to get the log(s) before connecting the regular monitor and before adding the VR monitor.
  • You could also reboot, and the “Xorg.*.log.old” would be known as being from the previous boot. These would be only for the VR goggles since the regular monitor was not connected.

Note that there are “Magic SysRQ” key bindings which can help you safely shut down even with no monitor if you have a local keyboard attached. This would be the sequence of keystrokes to use if you have no other login access from ssh or serial console (note that sysrq is the same key as the “PrtScn” key, but without a shift; PrtScn is with shift):

  1. ALT+sysrq+s
    (this will sync the filesystem)
  2. ALT+sysrq+s
    (this will sync the filesystem again; the second sync makes sure the first sync completed)
  3. ALT+sysrq+u
    (this will remount the filesystem read-only)
  4. ALT+sysrq+b
    (this will shut down the system or boot it)
  5. It is now safe to plug the regular monitor back in and boot to look for logs.

If you want to see how this works before actually using “Magic SysRq”, then monitor “dmesg --follow”, and then try to sync once with ALT+sysrq+s. The log will show emergency sync. The “Magic SysRq” works even when most of the system has crashed and burned.

Note that if you have ssh or serial console access, then you don’t need to reboot, you can just copy the VR log files somewhere and then attach the regular monitor. The “Magic SysRq” keys are only if you cannot log in and save log files via ssh or serial console.

13

xorold0.txt (2.1 MB)
xorold1.txt (1.8 MB)
these I believe are the logs that now only contain the VR display stats. What is interesting to me is it seems like log1 is a continuation of log0 now, and thus the timestamps are no longer in sync? Also, the logs are still both very long and the display appears to initialize over and over, even though it stayed plugged in the entire time. Anyways, do these logs any offer insight into a potential fix?

14

Something is odd about the log files themselves. Were these from an Xorg.*.log.old, or did the original files not include “.old”? I’ll go through and make notes here as I go.

You are correct that these are not log files from a single session. It is building a “ModePool” over and over. I would expect this to occur twice at most for stereo VR. I counted eight occurrences of building the mode pool in the first log, all on port DFP-0.

In the first log I see this for accepted modes of the VR:

[     5.565] (II) NVIDIA(GPU-0): --- Modes in ModePool for LZT YongXing (DFP-0) ---
[     5.565] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[     5.565] (II) NVIDIA(GPU-0): "2880x1440"          : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[     5.565] (II) NVIDIA(GPU-0): "2880x1440_60"       : 2880 x 1440 @  60.0 Hz  (from: EDID, Detailed)
[     5.565] (II) NVIDIA(GPU-0): "640x350"            :  640 x  350 @  85.1 Hz  (from: EDID)
[     5.565] (II) NVIDIA(GPU-0): "640x350_85"         :  640 x  350 @  85.1 Hz  (from: EDID)
[     5.565] (II) NVIDIA(GPU-0): --- End of ModePool for LZT YongXing (DFP-0): ---

Both logs are just this same thing repeating over and over, which should not happen. It is as if the server is restarting as soon as it gets the mode pool set up. However, I don’t see a disconnect event.

This says that the Jetson accepts the above modes. Those are a subset which is in common to both the Jetson and the VR headset. This does not necessarily mean anything 3D/stereo will work, but it does say you should at least have a large virtual desktop. I don’t know if perhaps this is truly a separate desktop from the regular monitor or if this is trying to mirror the two when both are connected. Have you checked the VR headset when it is the only thing connected? I’m guessing that probably you have, but I have to ask.

So here is some debug context: If you have one or more monitors connected, and you log in via ssh or via serial console, then you cannot just start a program up which uses the X server. This is because they do not have the environment variable set up for the display context. These logs are odd, and normally I would say you could just refer to the log name to figure out which context to use. In this case the context might be “:0” or “:1”, and perhaps this is valid for stereo. If you happen to have both VR goggles and a regular monitor, then you might have two contexts, one for the regular monitor, and one for the VR headset not in stereo mode (the headset could function as a single large desktop). For these cases it might be any of what follows, and the numbers themselves might vary (the numbers are basically related to the order of detecting displays, and would not be set in stone if they detect in different orders):

  • Setting one ssh login for “export DISPLAY=:0”, and in another ssh login, “export DISPLAY=:1”. This is for two monitors. This could also be if only VR is connected and each eye is used as an independent monitor (I do not believe the latter example case would occur, but adding it for completeness).
  • Setting one ssh login for “export DISPLAY=:0”, and in another ssh login, “export DISPLAY=:1”. Additionally, another ssh login could be “export DISPLAY=:3”. This is for a stereo mode where left and right eyes are independent monitors, plus there is a third monitor.

Basically, if you have any remote login to your Jetson while a display is running, and you do nothing special, then running an X program (such as simply typing “xterm” on the command line) will fail because that terminal does not have the DISPLAY environment variable linking it to the monitor context.

If you do have a remote login, and in that login you’ve run the command “export DISPLAY=:0”, then running the X program “xterm” would cause the terminal to display on that monitor. It doesn’t have to be the “xterm” command, it could also be something like firefox or a file manager (anything requiring the GUI).

There is only one serial console. If you want to experiment with your regular monitor also attached, then first try “export DISPLAY=:0” and run a command like “xterm” and see if it displays to the regular monitor. If this does display there, then you know all other contexts are for the VR goggles. If this fails to display on the regular monitor, then instead overwrite the old export via “export DISPLAY=:1”. After that check again to see if some GUI program (such as xterm) will display on the regular monitor. Maybe it will be :3, I don’t know. It is trial and error.

The nice thing about an ssh login is that you can have several logins at the same time. Just make sure they are logged in to the user name you are testing with. See if anything displays, although there is a catch: If the VR does have a valid display, but if you are not logged in to it, then the attempt to bring up a program like xterm will be rejected. The real test is this: If VR and regular monitor are the same mirrored display, then even if nothing shows up, attempting to launch a program should succeed (but you might not see it). I am curious what shows up when you manually try to do this.

Also, you might start by deleting the old “/var/log/Xorg.*.log*” files (or copy them somewhere, but we won’t be using them). Then reboot so that you are guaranteed that the logs are from some point after you deleted. Find out which logs show up after reboot.

Overall, it is suspicious that the same ModePool is being created over and over and over non-stop without any kind of crash message. Maybe some new detail from the above will offer a clue. You might also provide a copy of the output of “dmesg” after the system is up. You could for example:
dmesg 2>&1 | tee log_dmesg.txt
(and then attach “log_dmesg.txt”; just do this after at least the regular monitor works and when VR is plugged in).

15

SSH with the display seems not to work at all. After successfully remotely accessing the nano and exporting the correct context, I cannot run xterm, Firefox, or any application. I tried with both the working monitor and the VR monitor. Both times it says “could not access display”. The logs I provided were the .old logs from a boot where I only used the VR monitor. Also, I did only have the vr monitor attached when I provided the xorg logs. Could you describe to me in more detail how to use dmesg and what it will provide?
I experimented further with the display and researched a bit, and tried to set the resolution with XRANDR. It did not work at first trying to set it to 2880x1440@60, even when I made it a custom mode, it would tell me “could not find mode”. However, if I set it to 640x350, it worked but displayed triplicate and glitched and only on the right screen. Once it was like this, I tried again to set it to 2880x1440, and this time it worked with no error message, but the display went completely Black.
I am most interested in why the display worked perfectly during the installation phase and as soon as the OS was installed it stopped working. The fact that the display works during boot suggests that something in the boot file or in config somewhere is ruining the display initialization. I am going to retrieve the xorg log from first installation when the display actually works for a second by reflashing my operating system. Also, would it be useful to provide my extlinux config and xorg config?

EDIT: it appears there is a button on the display board that switches between displaying one screen split between the two, and a single 1440 feed on each. I figured this out while in installation while the display actually works. Also, I believe the only reason the screen displays during the flashing process is because SDK manager forces HDMI output while the nano is still connected to the computer. Maybe Wayne is right and the nano just can’t output this resolution.

16

What was your ssh command line? Specifically, if you entered “-X” or “-Y”, then it is fighting with a context on your local computer (the Jetson is remote in this case). Did you try with only the regular monitor? This part should be reliable, and if it doesn’t work, then it would be interesting to find out why.

On the regular monitor, in a local terminal at that monitor, run the command:
echo $DISPLAY

This will tell you what to export. Then, go to your other computer, ssh with no options to the Jetson. Run the command “export DISPLAY=':0'” (or adjust for “:1” or whatever it said from the earlier echo). A command like xterm (or firefox) should display on the regular monitor of the Jetson.

If that works, then you can connect the VR headset with the following procedure:

  • Leave the original monitor running; you will be logging in a second time while leaving the first ssh running.
  • Run the command “ls -ltr /var/log/Xorg.*.log”. Note that the last log listed will have the most recent timestamp. You will compare this in a moment, so maybe mouse copy and paste the log name and timestamp (this is the one your regular monitor is using).
  • If you monitor “dmesg --follow” while connecting the VR headset, then it might tell you the DISPLAY. If not, then if you can again run “ls -ltr /var/log/Xorg.*.log”. If the same log file is the most recent one to be touched, but has a newer timestamp, then it implies probably the VR is using the same context as the regular monitor. If there is a new log file, then the naming of that log file should indicate what the $DISPLAY is. For example, if the regular monitor shows as “:0” before attaching VR, then probably VR would be “:1” and the log file name might be Xorg.1.log. We’re trying to trick it into telling us the context, but it depends on the ssh working to display to the original monitor first to prove that the system can function that way.
  • If you succeed up to there, then with a new ssh connection try to run xterm (or any GUI program) again with a new “export” (such as “export DISPLAY=:1”). Obviously, if you cannot display something on the regular monitor like this, then I would expect it to fail on the VR headset as well.

You won’t be able to set up custom modes, this is the nature of the integrated GPU (iGPU); a discrete GPU (dGPU) has more options than the Jetson iGPU. However, if you look at the modes I copied from the logs for the “ModePool”, then those should be visible when using xrandr (this is tied to the $DISPLAY). Setting to one of those modes which show up in ModePool and xrandr should work if the $DISPLAY is valid.

There are a number of reasons why install might work, but not in normal operation. Often this relates to the device tree (which is firmware). The device tree is used to tell the kernel drivers where various hardware is, and what drivers to associate with them. If you have a developer’s kit, which is what this forum is designed for helping with, then the device tree won’t be a problem. However, if you have a third party carrier board, then the device tree is likely incorrect and some functions will fail due to not properly finding and associating drivers to hardware.

The case of watching “dmesg --follow” while you plug in a monitor, and seeing that plug-in was detected, is a subset of what that device tree works with, but would show at least some of the tree is valid (the hot plug detect wiring). If an EDID is retrieved (which is what tells the driver about the modes to consider in custruction of the ModePool), then the i2c for detection is also valid. Perhaps it works with the regular monitor, but not the headset; both would need device tree setup. Do be certain to tell us if this is using a third party carrier board.

I also must ask, and perhaps sooner, does this VR headset use an HDMI or DisplayPort connector? Hopefully this is the case, because if it uses USB-C, then the drivers do not know how to handle this (USB is for plug-n-play whereby devices can self-describe, the description is broadcast, and drivers which can handle this will take ownership of the device; this is similar to how the hot plug detect and query of the HDMI or DisplayPort works).

The driver used during flash or initial setup will usually differ from running since the driver for flash is in boot content, but the driver while running is from the Linux kernel.

It might be useful to see extlinux.conf and the xorg.conf.

If the query of a monitor (or VR headset) builds a ModePool, then that selection of modes would be supported. There are a lot of modes which have no support, but if you look in the logs, then if you find a mode not supported, then the verbose log will say that mode was rejected. Note that every mode is commented on in verbose logs, and then the ModePool is a summary of accepted modes.