I took the suggestion from @Honey_Patouceul and followed this archlinux xrandr page to permanently add 1080p as a default in a “Monitor” section in xorg.conf. I added the lines to both xorg.conf and xorg.conf.jetson_e and it worked perfectly. Every reboot with the KVM now defaults to 1080p after xserver starts!
Also, NoMachine has no impact on this since I’m logging in as the only user set up on the system, and the desktop is already active. It’s not creating a separate “display” for any other user when I connect to it.
My original post was incorrect as well. They’re using a KVM that gives an invalid EDID. Forcing the monitor to always be 1080p via xorg.conf was definitely the solution.
Thanks for all of the help and suggestions. I’m just posting this to make sure others have the same info that I do just in case anyone else runs into this issue.
Welp, I thought it had fixed the issue, but I was mistaken. A manual reboot from the desktop, and a “sudo reboot” from terminal both went to 1080p, but an automated reboot overnight via crontab reset it back to 720x400 this morning. No idea why.
Here’s my xorg.conf if anyone wants to help debug this:
# Copyright (c) 2011-2013 NVIDIA CORPORATION. All Rights Reserved.
#
# This is the minimal configuration necessary to use the Tegra driver.
# Please refer to the xorg.conf man page for more configuration
# options provided by the X server, including display-related options
# provided by RandR 1.2 and higher.
# Disable extensions not useful on Tegra.
Section "Module"
Disable "dri"
SubSection "extmod"
Option "omit xfree86-dga"
EndSubSection
EndSection
Section "Device"
Identifier "Tegra0"
Driver "nvidia"
# Allow X server to be started even if no display devices are connected.
Option "AllowEmptyInitialConfiguration" "true"
Option "UseEdid" "False"
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Tegra0"
SubSection "Display"
Depth 24
Virtual 1920 1080 # Modify the resolution by editing these values
Modes "1920x1080_60.00"
EndSubSection
EndSection
Section "Monitor"
Identifier "HDMI-0"
Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120$
Option "PreferredMode" "1920x1080_60.00"
EndSection
The reason I’m skipping using the EDID is the KVM that’s attached to the jetson gives me an invalid EDID according to xrandr:
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
HDMI-0 connected primary 1920x1080+0+0 (0x18e) normal (normal left inverted right x axis y axis) 1000mm x 680mm
Identifier: 0x18c
Timestamp: 4392026
Subpixel: unknown
Gamma: 1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC: 0
CRTCs: 0
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
TegraOverlayBlendmode: Opaque
supported: Opaque, SourceAlphaBlend, PremultSourceAlphaBlend
TegraOverlayPriority: 255
range: (0, 255)
EDID:
00ffffffffffff00f1c8b35a9eaa3559
bdb06162fa6444b88ed8c15e5bf7679e
53e0d093f82e6da0b1cc607274423203
0589cc39b045c8e16142b33f8fbbbbcf
5fd59bf932d8e776d4e079153c0304f2
5235784d36f7727af674cbb41c89256e
e846b7dc78f66d88793d2bdb3a59b028
a53784f47bee715fd1c90171e258011c
02031b61230907078301000067030c00
2000802d43908402e2000f8c0ad08a20
e02d10103e9600a05a00000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000029
If you run that EDID through an EDID Reader, it comes back as invalid, thus all of the effort to just ignore the EDID and set a permanent resolution. But, alas, this didn’t work from an automated reboot.
You might want to add this to the xorg.conf in Section “Device”:
Section "Device"
Option "ModeDebug"
...
What this will do is cause the X server to log everything related to both possible modes and requested modes. Let the driver itself tell you why this happens. Then save a copy of the log when it booted correctly for comparison to when it fails. Note that the log is numbered after the “$DISPLAY” environment variable. Normally it would start at “/var/log/Xorg.0.log”, but if your result from “echo $DISPLAY” were say “10” (a subset of “:10”), then the log will be “/var/log/Xorg.10.log”. You can see the order of logs (in case there is both a local and a remote log) via: ls -ltr /var/log/Xorg.*.log
(the most recent log is at the bottom of the scroll, sorted to least recent at the top of the list of logs)
Just make sure you get one log from when it boots correctly, and one from when it does not boot the server correctly. The log would be from the Jetson end. In the case of NoMachine, it is possible there might be other logs at the host PC, but I’m not sure which logs that might be, and those logs are most likely irrelevant since it is the Jetson side’s resolution you are working on.
I’ve added this to the xorg.conf. on my next reboot, i’ll double check the log files and come back to post here.
Also, @Honey_Patouceul, I used the xrandr line you gave and it worked. Thanks for the clarification on that. Now that I have the proper EDID information, is there a way to tell xorg “If you see this EDID, force the resolution to 1080p only”?
nvidia-xconfig is for discrete GPUs (dGPU) which are on the PCI bus. Jetsons have an integrated GPU (iGPU) which is directly wired to the memory controller. So nvidia-xconfig does not apply to Jetsons. Any driver which works with nvidia-config will actually break the Jetson. The xrandr is how most Linux systems would configure X, and Ubuntu with an iGPU also uses that. It does make me wonder though how many ways the NVIDIA devs use for that configuration (other than xrandr and the xorg.conf file).
EDIT: It looks like I’m partially wrong about the above. It looks like L4T R35.x has nvidia-xconfig in package nvidia-l4t-x11. However, I only find this in L4T R35.x, not R32.x. Older Nano cannot use this release, one would need Xavier or Orin to use that release. Still, it is fascinating because I thought this was due to needing nvidia-smi (a dGPU uses that via PCI). Thanks for @Honey_Patouceul pointing out that there is an nvidia-xconfig, although I don’t see it as available for plain vanilla Nano. I suppose that does not help Nano users, but it seems worth mentioning.