AGX Thor: monitor connected with DP port can't display with 3440x1440 165Hz

Robotics & Edge Computing Jetson Systems Jetson Thor
1

image
image818Ă—311 7.92 KB

The display panel supports 3440x1440 resolution at 60Hz, 100Hz, 120Hz, and 144Hz without issues. However, attempting to set the resolution to 3440x1440 @ 165Hz results in a black screen. Relevant kernel logs are provided.

The failure at 165Hz might be linked to display-t264-dce.binor the NVIDIA driver module (nvidia_drv.so). As these are closed-source, what is the standard procedure for isolating the root cause in such scenarios? Thanks!

display_issue.txt (3.1 KB)

3

Hi @xus,

Thanks for the log. The signature we’re seeing — display engine idle timeout followed by a DCE RPC timeout — tells us the hang happens during mode commit on the 165Hz attempt specifically. To go further we need a bit more context around that moment.

Could you share the following first?

  1. BSP / JetPack version — cat /etc/nv_tegra_release
  2. Full dmesg from boot through a failed 165Hz attempt — run dmesg > dmesg_165hz.log right after the black screen occurs

While you’re collecting that, it would also help to try a different DP cable — ideally one rated DP 1.4 / HBR3 (often marketed as “8K” or “HBR3 certified”). 3440x1440 @165Hz may push the link to HBR3, which is much less tolerant of marginal cables than the rates that work for you today. If a known-good cable makes 165Hz work, that alone tells us the Thor side is fine and the original cable is the limiting factor.

Once we have the dmesg + BSP version (and cable test result if you can), we’ll know whether to look at the link-training path or the DCE-side commit path next.

Hope this helps!

4

journal_165hz.log (795.2 KB)

nv_tegra_release.txt (307 Bytes)

Hi wichiu, thanks for your reply. As our product uses a Mini DisplayPort (Mini DP) interface. Currently, we do not have any other devices available to verify whether the Mini DP cable in use supports 3440x1440 resolution at 165Hz.

5

Could you run xrandr --verbose > xrandr_144hz.txt while the display is at a working 144Hz mode? That single output shows the detailed timing per mode plus the current DP link rate and lane count, which should tell us what’s different between 144Hz (works) and 165Hz (hangs).

Thanks!

6

xrandr_144hz.txt (8.9 KB)

xrandr_165hz.txt (8.9 KB)

The logs are attached.

8

Hi xus,

Thanks for the xrandr captures. Could you do the following thing to me?

1. Enable ModeDebug and collect /var/log/Xorg.0.log.

Add Option "ModeDebug" "true" to the Device section of /etc/X11/xorg.conf (create the file if it doesn’t exist):

Section "Device"
    Identifier     "Tegra0"
    Driver         "nvidia"
    Option         "ModeDebug" "true"
EndSection

Restart X (or reboot), reproduce the 165Hz black screen once, and attach the full /var/log/Xorg.0.log.

Thanks!

10

Xorg.0.log (589.6 KB)

The log reproduce the 165Hz black screen with Option “ModeDebug” “true” is attached.

13

Hi xus,

We reviewed the ModeDebug log again and found one possible bandwidth-related explanation.

Your monitor EDID advertises 10 bits per component support. If the driver selects 10 bpc RGB output for 3440x1440 @ 165 Hz, the required DP payload bandwidth is approximately:

879.71 MHz pixel clock * 30 bpp = ~26.39 Gbps

This is higher than the DP HBR3 4-lane payload bandwidth of ~25.92 Gbps. In comparison:

  • 3440x1440 @ 165 Hz at 8 bpc RGB requires ~21.11 Gbps, which fits within HBR3.
  • 3440x1440 @ 144 Hz at 10 bpc RGB requires ~24.00 Gbps, which also fits within HBR3.

This is not confirmed as the only cause yet, but it is consistent with the 144 Hz / 165 Hz boundary we see in the logs.

Recommendation: please keep using 3440x1440 @ 144 Hz as the stable setting. If your desktop or monitor settings provide an option to force 8 bpc / 8-bit color output, you can also try 3440x1440 @ 165 Hz with 8 bpc.

References:

Hope this helps!

15

OK, thanks! We’ll try this solution and feedback.