Trouble displaying specific screens

[WayneWWW]

then you can copy what you saw on the screen and paste to an editor…?

[linuxdev]

Some details that might be helpful to you…

Whenever you run “some_command > name.txt” it will produce that “name.txt” as a file from where you ran that command. This only works if you are in a directory you have permission to write to. Your home directory has the alias “~”, the tilde key, so you could:

# This puts you in your home:
cd
# This is the same and also puts you in home:
cd ~

# This produces the name.txt (if in home, it goes in home):
some_command > name.txt

# This should verify:
ls name.txt
# This is the same if you were in home:
ls ~/name.txt

Even better is to understand that this is the “standard output”. There is also a “standard error”. “standard error” has a file descriptor “2”, while the standard output has descriptor “1”. You’re already logging standard output that way. To log any command, including standard error, and to see the standard out and error in the log, plus see the actual command output, you append this:
2>&1 | tee name.txt

That “2>&1” redirects standard error to standard out, and then pipes it to tee, and tee both shows you what it sees and creates the log. Example:
some_command 2>&1 | tee ~/name.txt
(the above should always work and show you the command output)

If you use a serial console program, which runs from a host PC, this can log everything onto the host PC, which is rather convenient.

Incidentally, Jetson GPUs are integrated directly to the memory controller (an iGPU), whereas most desktop PCs are discrete GPUs (dGPU), going through the PCI bus. Their drivers are different and not compatible with each other. The iGPU driver is using a wire between the monitor and GPU to query your monitor and ask it for its specs. If it cannot use that spec, then the mode is not available. A discrete GPU has some ways to override a few parameters which are not available on the iGPU.

If you want to see exactly what the driver thinks of every mode the monitor publishes for its specs, edit the file “/etc/X11/xorg.conf”. Find Section "Device". Add Option "ModeDebug". Sort of like this:

Section "Device"
   Option "ModeDebug"

(the rest of the section just stays the same; you need to edit with sudo)

After that, if you reboot, and if that monitor is either connected or plugged in before looking at the log (HDMI is “hot plug”), then you will have a log which verbosely tells you everything about every mode of the device, and what the driver thinks of every mode. I suggest add ModeDebug, and then post the resulting log.

I wouldn’t bother this next explanation, but the log file name might differ for stereo VR. Every GUI display will have a “context”, and if you are logged in to a GUI, you can see this with “echo $DISPLAY”. Usually it is “:0”. This is why there is a 0 in the log file name “/var/log/Xorg.0.log”. If you had two displays, then there would be a separate log for each $DISPLAY, and there would be two logs. If you do this, then you will see the logs present, along with being sorted by timestamp:
ls -ltr /var/log/Xorg.*.log

The last line is the most recent timestamp. If you see both “Xorg.0.log” and “Xorg.1.log”, and if both are from current date and time, then you would want to post both logs. Most likely you only need one log. There might be some “Xorg.*.log.old” files from previous boots, but you can ignore those. Those can also be useful though, if for example you booted up with the monitor, something crashed, and you rebooted with a different monitor; in that case the “/var/log/Xorg.0.log.old” would be from the previous session’s crash.

HDMI is hot-plug, and so if a server is running, and you unplug and replug a monitor, or if you plug in a different monitor on the same GUI server, then “/var/log/Xorg.0.log” will just continue increasing in size as it logs new monitors. If you have ModeDebug in the xorg.conf, then the plug-in event (which happens for normal boot as well if the monitor was attached during boot) will repeat each event within a single file (that’s a lot of logging, and I’m not suggesting you unplug and replug, but it is nice to know how to understand when debugging).