Headless fullscreen RANDR usage with ConnectedMonitor has restricted resolution on even-numbered ports

This is a follow-up from the above topic.

More references:

Tagging @amrits to carry on from bug 4260425.

So, the issue in the above topic got partially solved, but one issue still remains.

This was written by @pagzma09 but this explains the currently remaining issue and thus I bring it here:

In version 545.29.02 and also very likely 535.129.03 and later versions:

When a monitor is marked with “ConnectedMonitor” the maximum pixel clock rate is reduced to HDMI 1.0’s 165.0 MHz and the driver subsequently seems to think it will need to use “Display Stream Compression” in order to transmit 4K images. When the card doesn’t offer DSC, this triggers the “extended capability check failed” error.

It’s unclear to me why the driver would enforce dropping the maximum clock rate all the way to HDMI 1.0’s 165.0 Mhz. At the very least, I would think there be an option to set the maximum clock rate for the ConnectedMonitor rather than simply assume the monitor is only capable of HDMI 1.0. Obviously, the overrides would normally be able to deal with this, but at the same time, dropping the maximum pixel rate this low means everyone trying to use the “ConnectedMonitor” options has to figure out on their own that these two options are also required before they’re able to get high resolutions working. If this is truly the intended behavior, perhaps a note in the documentation explaining this behavior under ConnectedMonitor would be worthwhile?

My remote desktop software doesn’t work when no displays are attached.

Some desktop environments or window managers might not function correctly if no displays are exposed via the RandR API. When the NVIDIA X driver is configured for headless operation, either with ‘Option “AllowEmptyInitialConfiguration”’ and no connected displays, with ‘Option “MetaModes” “NULL”’, or with ‘Option “UseDisplayDevice” “none”’, it will not expose any displays via RandR.

To work around software that requires RandR displays on a machine that is only intended to be used remotely, you can connect a physical display, or configure the X driver to behave as if a physical display were connected using the “ConnectedMonitor” option. See Appendix B, X Config Options for additional information about the “ConnectedMonitor” option.
Chapter 8. Common Problems

Using “ConnectedMonitor” to enable RandR without connecting a physical display is a documented feature of the drivers.

However, even with all the Mode Validation Overrides, the X server rejects any mode that is above the Pixel Clock of 165 MHz in even-numbered ports.
This is a serious issue especially when using an X server with a Jetson, where the luxury of a real monitor rarely exists.

If there is no monitor connected, RandR is not usable in larger resolutions.

[2066461.770] (WW) NVIDIA(GPU-0): Validating Mode “1280x800d60”:
[2066461.770] (WW) NVIDIA(GPU-0): Mode Source: X Server
[2066461.770] (WW) NVIDIA(GPU-0): 1280 x 800 @ 60 Hz
[2066461.770] (WW) NVIDIA(GPU-0): Pixel Clock : 174.25 MHz
[2066461.770] (WW) NVIDIA(GPU-0): HRes, HSyncStart : 1280, 1380
[2066461.770] (WW) NVIDIA(GPU-0): HSyncEnd, HTotal : 1516, 1752
[2066461.770] (WW) NVIDIA(GPU-0): VRes, VSyncStart : 800, 801
[2066461.770] (WW) NVIDIA(GPU-0): VSyncEnd, VTotal : 804, 829
[2066461.770] (WW) NVIDIA(GPU-0): Sync Polarity : -H +V
[2066461.770] (WW) NVIDIA(GPU-0): Extra : DoubleScan
[2066461.770] (WW) NVIDIA(GPU-0): Mode is rejected: Unable to construct hardware-specific
[2066461.770] (WW) NVIDIA(GPU-0): mode timings.
[2066461.770] (WW) NVIDIA(GPU-0): GPU extended capability check failed.
[2066461.770] (WW) NVIDIA(GPU-0): Mode “1280x800d60” is invalid.

[2066461.769] (II) NVIDIA(GPU-0): Validating Mode “1920x1200_60”:
[2066461.769] (II) NVIDIA(GPU-0): Mode Source: X Server
[2066461.769] (II) NVIDIA(GPU-0): 1920 x 1200 @ 60 Hz
[2066461.769] (II) NVIDIA(GPU-0): Pixel Clock : 154.00 MHz
[2066461.769] (II) NVIDIA(GPU-0): HRes, HSyncStart : 1920, 1968
[2066461.769] (II) NVIDIA(GPU-0): HSyncEnd, HTotal : 2000, 2080
[2066461.769] (II) NVIDIA(GPU-0): VRes, VSyncStart : 1200, 1203
[2066461.769] (II) NVIDIA(GPU-0): VSyncEnd, VTotal : 1209, 1235
[2066461.769] (II) NVIDIA(GPU-0): Sync Polarity : +H -V
[2066461.769] (II) NVIDIA(GPU-0): DualHead Mode: No
[2066461.769] (II) NVIDIA(GPU-0): Viewport 1920x1200+0+0
[2066461.769] (II) NVIDIA(GPU-0): Horizontal Taps 1
[2066461.769] (II) NVIDIA(GPU-0): Vertical Taps 1
[2066461.769] (II) NVIDIA(GPU-0): Mode “1920x1200_60” is valid.

nvidia-bug-report.log.gz (295.2 KB)
Xorg.0.log.gz (20.0 KB)
xorg.conf.log.gz (780 Bytes)

1 Like

Also eproducible on RTX 3090. Looks like this behavior of 165 MHz don’t exactly conform to even-numbered digit ports (only for the TITAN Xp), but ports DFP-{0,2,3,5}. This includes DP ports as well as HDMI.

Xorg.0.log.gz (18.9 KB)
xorg.conf.gz (777 Bytes)

@ehfd
I acknowledge the thread, will take it forward to right person and update.

Thank you. I always enjoy working with NVIDIA.

Hi @ehfd
Could you please help to test fix with driver 550.40.07 and share results. https://download.nvidia.com/XFree86/Linux-x86_64/550.40.07/NVIDIA-Linux-x86_64-550.40.07.run