How to set permanent display resolution

Continuing the discussion from How do I set a permanent display resolution?:

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.

1 Like

Thanks for sharing!

1 Like

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"

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"

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"

Section "Monitor"
   Identifier "HDMI-0"
   Modeline "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120$
   Option "PreferredMode" "1920x1080_60.00"

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
	CRTC:       0
	CRTCs:      0
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	TegraOverlayBlendmode: Opaque 
		supported: Opaque, SourceAlphaBlend, PremultSourceAlphaBlend
	TegraOverlayPriority: 255 
		range: (0, 255)

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.

Where do we go from here?

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.

Additional note about edid reader:
The output of xrandr may not be directly suitable for

Be sure in that you have the Add Hex Prefix (0x) checked, then paste the output of:

xrandr --props | grep -A 16 EDID | tee | tail -16 | tr -d '\t' | sed 's/../& /g;s/:$//'

That should be 16 lines of 16 hex bytes separated by a space.

You may also have a look to : X Window System — Jetson Linux Developer Guide documentation

1 Like

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”?

Also, I got this from trying nvidia-xconfig:

bash: nvidia-xconfig: command not found

and it isn’t found in any apt install repos

EDIT: See the “qualification” below.

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.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.