Display Issue with Certain DP-to-HDMI Adapters on R36.4.4 (AGX Orin)

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
,
1

Hi,

After upgrading to Jetson Linux R36.4.4, we encountered a display issue depending on the DP-to-HDMI adapter used.

Issue Description

Display output fails with specific DP-to-HDMI adapters after updating from R36.3.0 to R36.4.4.

Test Environment

  • Board: NVIDIA Jetson AGX Orin Dev Kit

  • Software:

    • Jetson Linux R36.3.0 / JetPack 6.0

    • Jetson Linux R36.4.4 / JetPack 6.2.1

  • Connection:

    • AGX Orin → DP-to-HDMI adapter → TV

Test Results

We tested using the same AGX Orin dev kit with two different DP-to-HDMI adapters and two different OS images.

Case 1: Jetson Linux R36.3.0

  • Normal adapter → TV display: OK

  • Problematic adapter → TV display: OK

Case 2: Jetson Linux R36.4.4

  • Normal adapter → TV display: OK

  • Problematic adapter → TV display: FAIL

Observation (HOT PLUG Signal Behavior)

Waveform data is attached for reference.

Question

  • Are there any changes in DP/HDMI hotplug handling or display driver behavior between R36.3.0 and R36.4.4?

  • Is there any recommended workaround or patch for improving compatibility with certain DP-to-HDMI adapters?

2

*** Please note that this reply is generated by LLM automatically ***

The issue you’re experiencing with the display output failing with specific DP-to-HDMI adapters after updating from R36.3.0 to R36.4.4 on the Jetson AGX Orin Dev Kit is likely related to changes in the DP-HDMI hotplug handling or display driver behavior between the two versions.

In R36.4.4, the device tree structure has changed, and the compiler has been updated to Bootlin gcc 11.3.0 2022.08-1 aarch64 toolchain. Additionally, there are carrier board customization notes for modifying the display from the default DP to HDMI.

Comparing the two cases you provided, it appears that the HOT PLUG pin signal behavior has changed between R36.3.0 and R36.4.4. In R36.3.0, the HOT PLUG signal remains stable during boot and cable reinsertion, with no momentary drop to LOW observed. In contrast, in R36.4.4, the HOT PLUG signal shows a brief drop to LOW depending on the adapter used.

This change in behavior could be related to the updated display driver or changes in the DP-HDMI hotplug handling. Unfortunately, without more information on the specific changes made between R36.3.0 and R36.4.4, it’s difficult to pinpoint the exact cause of the issue.

However, there are a few potential workarounds you could try to improve compatibility with certain DP-to-HDMI adapters:

  1. Check the device tree structure: Ensure that the device tree structure is correctly configured for your specific use case. You can refer to the AGX Orin Device Tree Structure and Orin NX/Nano Device Tree Structure guides for more information.
  2. Update the display driver: Try updating the display driver to the latest version available for R36.4.4. You can check the NVIDIA website for the latest drivers and installation instructions.
  3. Modify the carrier board configuration: If you’re using a custom carrier board, try modifying the configuration to use a different display output or adapter. You can refer to the Display Configuration And BringUp guide for more information.
  4. Apply a patch: If you’re experiencing issues with a specific DP-to-HDMI adapter, you can try applying a patch to the display driver or kernel to improve compatibility. However, this would require more advanced technical knowledge and may not be feasible for all users.

In summary, the issue you’re experiencing is likely related to changes in the DP-HDMI hotplug handling or display driver behavior between R36.3.0 and R36.4.4. You can try updating the display driver, modifying the carrier board configuration, or applying a patch to improve compatibility with certain DP-to-HDMI adapters. However, without more information on the specific changes made between the two versions, it’s difficult to provide a more detailed solution.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

3

Hi, thanks for your response.

However, I have a few concerns regarding your suggestions.

First, this issue was reproduced on the AGX Orin Dev Kit (reference board) using unmodified original images for both R36.3.0 and R36.4.4.

So I’m not sure why checking the device tree structure or carrier board configuration would be relevant in this case, since:

  • No custom carrier board is used

  • No device tree modifications were applied

  • The same hardware setup works correctly on R36.3.0

    Additional Questions

    1. Is there any known change in HPD (Hot Plug Detect) handling between R36.3.0 and R36.4.4 at the driver or firmware level?

    2. Is there any way to:

      • Disable HPD re-triggering

      • Or add delay/workaround in the driver for unstable adapters?

5

Hi nyx,

Thank you for the detailed investigation — the oscilloscope waveform comparisons are excellent and clearly show the behavioral difference in HPD signaling between R36.3.0 and R36.4.4. This is very helpful for narrowing down the issue.

You’re right that the previous suggestions about custom device tree modifications and carrier board configuration don’t apply here, since you’re using the reference AGX Orin Dev Kit with stock images.

Based on your findings, this looks like an HPD handling regression in R36.4.4 — the brief HPD LOW glitch during initialization is causing certain adapters (with less HPD bounce tolerance) to interpret it as a disconnect. To help us narrow this down further, could you collect the following:

1. Kernel logs during the failure
Boot with the problematic adapter connected, then capture the display-related kernel messages:

dmesg | grep -iE "hdmi|hpd|hotplug|dp|display|tegradc|nvdisplay" > dmesg_display_r36.4.4.txt

If possible, capture the same from R36.3.0 for comparison.

Purpose: Check whether the driver registers the HPD glitch as a false disconnect/reconnect event. If R36.4.4 shows repeated connect/disconnect messages that don’t appear in R36.3.0, it confirms the driver is mishandling the HPD bounce from certain adapters.

2. Display device tree comparison
Extract the display-related device tree from both versions:

# On R36.4.4
dtc -I fs -O dts /proc/device-tree 2>/dev/null | grep -A 20 "display\|dp\|hdmi\|hpd" > dt_display_r36.4.4.txt

# On R36.3.0 (same command)
dtc -I fs -O dts /proc/device-tree 2>/dev/null | grep -A 20 "display\|dp\|hdmi\|hpd" > dt_display_r36.3.0.txt

Note: The exact node names may vary — if these grep patterns don’t capture the relevant sections, you can also try extracting the full device tree with dtc -I fs -O dts /proc/device-tree > full_dt.dts and searching for display connector nodes.

Purpose: The device tree contains hardware-level configuration for the display subsystem, including HPD debounce timing and GPIO settings. Comparing the two versions will reveal whether any of these values changed between R36.3.0 and R36.4.4, which would directly explain the HPD behavior difference you captured on the oscilloscope.

3. Xorg or Wayland display logs
Depending on your display server:

  • Xorg: /var/log/Xorg.0.log
  • Weston: journalctl --user -u weston

Purpose: The display server sits above the kernel driver and manages actual screen output. Its logs show the higher-level consequences — whether it attempts to reconfigure outputs, loses track of the monitor, or hits errors re-establishing the display. Combined with your waveforms (hardware) and dmesg (kernel), this completes the full picture from signal to screen.

Recommendation: Given that this is a regression on the reference platform with stock images, and you have clear waveform evidence, this is strong enough to file as a regression bug. The logs above would strengthen the report by providing the complete evidence chain — from the HPD signal behavior (your oscilloscope captures) to the driver’s reaction (dmesg) to the display configuration impact (device tree + display server logs). If collecting these confirms the driver is mishandling the HPD bounce, we can also look into whether there’s a debounce parameter that can be adjusted as a temporary workaround while a proper fix is developed.

Hope this helps!

6

requested_logs.zip (59.6 KB)

As requested, I have collected and attached the logs from both R36.3.0 and R36.4.4 for comparison:

  • Kernel logs (dmesg)

  • Device tree excerpts (display / DP / HPD related)

  • Display server logs (xlog)

Thank you.

7

Hi nyx,

Thank you for collecting all the logs so quickly. After comparing the R36.3.0 and R36.4.4 data, we found several important clues.

Key findings from your logs:

1. Xorg logs confirm the HPD re-enumeration pattern
Your R36.4.4 Xorg log shows DFP-0 (Samsung SMT-2210) being re-detected 3 times at ~2-second intervals (t=22.5s, 24.6s, 26.9s) — this is abnormal and correlates with the HPD glitch you captured on the oscilloscope. In contrast, R36.3.0 shows a single connection event at t=25.4s with quick settling (~300-400ms re-enumeration gaps), which is normal initialization behavior.

This means even the working adapter triggers HPD re-enumeration events on R36.4.4 — for the problematic adapter with less HPD tolerance, these same events would cause an actual connection loss.

2. Device tree: no debounce parameters, but a new hdcp_enabled property
We compared the display@13800000 nodes between versions. The display configuration is structurally identical — and importantly, there are no HPD debounce parameters in either version, so a debounce configuration change is ruled out.

However, we found one notable difference: R36.4.4 has an hdcp_enabled; property in the display node that does not exist in R36.3.0. HDCP (High-bandwidth Digital Content Protection) authentication involves HPD re-assertion as part of its handshake protocol, and the ~2-second re-enumeration interval we see in the Xorg logs is consistent with HDCP retry timing. This could be the trigger — or at least a significant contributor — to the HPD glitch you observed.

3. dmesg shows no HPD-level events
Neither version’s dmesg output contains explicit HPD/hotplug messages, which means the HPD handling is occurring below the kernel log level (in the display driver or DP controller firmware).

Next step: test with HDCP disabled

To verify whether the hdcp_enabled addition is causing the HPD issue, could you try removing it from the R36.4.4 device tree?

# Extract the current DTB
sudo dtc -I dtb -O dts -o /tmp/tegra234-modified.dts /boot/dtb/kernel_tegra234-p3737-0000+p3701-0000-nv.dtb

# Edit and remove the "hdcp_enabled;" line from the display@13800000 node
sudo nano /tmp/tegra234-modified.dts
# (search for "hdcp_enabled" and delete that line)

# Recompile
sudo dtc -I dts -O dtb -o /tmp/tegra234-modified.dtb /tmp/tegra234-modified.dts

# Backup and replace
sudo cp /boot/dtb/kernel_tegra234-p3737-0000+p3701-0000-nv.dtb /boot/dtb/kernel_tegra234-p3737-0000+p3701-0000-nv.dtb.bak
sudo cp /tmp/tegra234-modified.dtb /boot/dtb/kernel_tegra234-p3737-0000+p3701-0000-nv.dtb

# Reboot and test with the problematic adapter
sudo reboot

Note: The exact DTB filename may differ on your setup — check /boot/dtb/ for the correct file matching your board (p3737-0000+p3701-0000 is the AGX Orin Dev Kit). If you have a different filename, substitute accordingly. After testing, you can restore from the .bak file.

Purpose: If removing hdcp_enabled resolves the HPD glitch, it confirms that HDCP handshake is the trigger for the HPD re-assertion behavior introduced in R36.4.4. This would also explain why only certain adapters are affected — adapters vary in their HDCP and HPD bounce tolerance.

Also, one quick clarification: were these logs collected with the working adapter or the problematic one? The Xorg logs show Samsung SMT-2210 connected successfully, so if this was with the problematic adapter, it would mean the display does eventually connect but with repeated HPD cycling. If it was with the working adapter, then the HPD re-enumeration pattern exists even when the display stays up.

Recommendation: Try the HDCP test above as the most targeted next step. If the issue persists after removing hdcp_enabled, we’d recommend upgrading to R36.5 (JetPack 6.3), which is the latest release — this issue may have already been fixed internally in the newer version.

Regardless of the outcome, we believe this is strong enough to file as a regression bug on the reference platform — you now have oscilloscope evidence, Xorg log evidence of HPD re-enumeration, and a concrete DT difference (hdcp_enabled) between the two versions. We can help draft the bug report once the test results are in.

Hope this helps!
Thanks

8

HI wichiu,
**
Please find my responses below:

A1.
When the hdcp_enabled property is removed and applied on R36.4.4, the HPD glitch is no longer observed in the waveform, and the display works correctly even with the problematic adapter.
(Note: The modification suggested on the dev kit did not persist after reboot, so I rebuilt and tested using my own modified BSP.)

A2.
When using the problematic adapter, the display does not show an image, but the TV does not report “No Signal.” Instead, it shows a black screen.
(As a clarification: since “No Signal” is not shown, it seems the HDMI connection itself is recognized, but no valid video output is being delivered.)

A3.
The same HPD glitch behavior is observed on R36.5.0, and the display still does not work with the problematic adapter.

As a temporary workaround, removing hdcp_enabled resolves the issue. However, if HDCP functionality is required, the problem still remains.

Is there any plan to address or fix this issue?

thanks

9

Hi nyx,

Thank you for the thorough testing — this confirms that the hdcp_enabled property is the root cause. The HDCP handshake triggers HPD re-assertion, and adapters with lower HPD bounce tolerance fail to maintain the connection, resulting in the black screen you observed.

Workaround options:

  1. Remove hdcp_enabled from the device tree — the only impact is that HDCP-protected content cannot negotiate content protection, which has no effect for most development and embedded use cases.

  2. Use a direct DP-to-DP connection if your setup allows — this is the most stable display path on the AGX Orin Dev Kit and avoids the issue entirely.

Regarding a fix:

We will file this internally as a regression. We cannot provide a specific timeline, but the evidence you’ve provided gives it a strong basis for being addressed in a future release.

Hope this helps!

12

Hi @nyx,

Quick update: L4T does not actually support HDCP, so removing hdcp_enabled; from the display DT has no functional impact. You can take it out directly without worrying about losing any feature.

Thanks.