HKC G27H7Pro redundant long-HPD loop after DisplayPort link training (RTX 5060 Laptop, 610.57.04)

NVIDIA Open GPU Kernel Modules Version

610.57.04 (release tag 610.57.04; reproduced with the RPM Fusion open kmod and traced with logging-only patches based on the same source release)

Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.

• I confirm that this does not happen with the proprietary driver package.

Operating System and Version

Fedora Linux 44 (KDE Plasma Desktop Edition)

Kernel Release

Linux pogi-fedora 7.1.10-200.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Aug 23 16:15:11 UTC 2026 x86_64 GNU/Linux

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.

• I am running on a stable kernel release.

Hardware: GPU

NVIDIA GeForce RTX 5060 Laptop GPU

Describe the bug

Issue Status

This issue has been fully root-caused, fixed in a locally patched build of the NVIDIA open kernel modules, and validated with both cold-login and complete logout/login tests.

This is not a speculative diagnosis. The complete event chain was traced across KWin, DRM, nvidia-drm, NVKMS, DPLib, and the RM callback boundary. The minimal source-level fix is known and confirmed effective.

User-Visible Failure

The system uses Plasma Wayland with an HKC G27H7Pro connected through DisplayPort as the primary display and the internal laptop panel as the secondary display.

During logout/login:

1. Both displays turn off during logout.
2. Both displays render the Plasma Login greeter correctly.
3. After authentication, the internal panel starts the user Plasma session normally.
4. The external HKC display remains physically black.
5. DRM and KWin still report the external display as connected and enabled at 3840x2160@160.
6. The pointer can move across the logical boundary between the internal and external displays.
7. The internal display and pointer freeze periodically at approximately 0.8-second intervals.
8. Suspending and resuming the system restores the external display and stops the periodic freezes.

The external output therefore never disappears from the logical desktop. The failure is a physical scanout/link-lifecycle failure, not an output-layout failure.

Confirmed Cause Chain

The complete causal chain is:

Plasma Login greeter drives both displays successfully
    -> DRM master is handed from the greeter to the user KWin session
    -> user KWin performs the required atomic modeset
    -> DP-5 / NVKMS DP-3 is configured for 3840x2160@160
    -> HBR3 x4 link training completes successfully
    -> NVIDIA RM reports a redundant long-HPD plug event
    -> DPLib treats the already-connected display as requiring reassessment
    -> DPLib performs another HBR3 x4 link training operation
    -> another redundant long-HPD event is reported
    -> the reassessment/training sequence repeats indefinitely

The raw RM callback repeatedly contains:

payload_plug=0x00001000
payload_unplug=0x00002000

0x00001000 is the HKC display:

DRM connector: DP-5
NVKMS connector: DP-3
NVIDIA display ID: 0x00001000
EDID name: HKC Overseas Ltd. G27H7Pro

The 0x00002000 unplug bit does not correspond to a currently connected display and produces no effective unplug action. The effective event is therefore another plug notification for DP-3 while DP-3 is already connected.

The event is already present in the raw RM callback payload. It is not generated by KWin, DRM uevents, nvidia-drm, or later NVKMS filtering.

No DPIRQ callback occurs during the event storm.

The DP Link Is Not Failing

The redundant events are not reporting a genuine link failure.

Every captured stable-state check shows a healthy HBR3 x4 link:

active link rate: 810
active lane count: 4
assessed link rate: 810
assessed lane count: 4

DPCD lane01 status: 0x77
DPCD lane23 status: 0x77
inter-lane alignment: complete
link-status-updated: false
DPCD offline: false
power state: active
bad lane mask: 0x0

All four lanes have:

clock recovery: complete
channel equalization: complete
symbol lock: complete

Every RM-controlled training operation also reports:

status=0x0
err=0x00000000
retry_ms=0
fallback=none
result=success

The active 4K160 display group is valid, with DSC and FEC enabled as required.

Therefore, DPLib is repeatedly retraining a link that it has already verified as fully operational.

Why the Desktop Freezes

Each redundant HPD event enters the NVKMS/DPLib link-assessment path and performs another two-stage HBR3 training operation against the LTTPR and sink.

During this operation, nvidia-drm waits synchronously inside the NVKMS atomic path. The captured atomic checks block for approximately 100-300 ms during every event cycle.

Because the RM callback repeats roughly every 0.8 seconds, the user observes:

pointer moves
    -> pointer and desktop freeze
    -> NVKMS training completes
    -> pointer moves again
    -> next redundant HPD arrives
    -> freeze repeats

The same feedback loop prevents the external display from maintaining stable scanout, leaving it physically black even though DRM reports it as connected, enabled, and assigned to a CRTC.

KWin is a victim of the blocking driver operation, not the source of the failure.

Why Suspend/Resume Recovers the Display

Suspend/resume forces a real DisplayPort lifecycle transition:

nvKmsSuspend
    -> nvRmPauseDP
    -> nvKmsResume
    -> nvRmResumeDP
    -> real unplug event
    -> DPLib zombieChange/lostDevice
    -> real plug event
    -> DPLib newDevice

Unlike the redundant events, this sequence changes DP-3 from connected to disconnected and then back to connected. DPLib destroys and recreates the device state, after which the external display begins scanning out correctly and the event storm stops.

This confirms that suspend/resume was resetting the broken DPLib device lifecycle, not correcting a KWin display layout.

Confirmed Source-Level Fix

NVIDIA already has the exact mechanism required for displays that generate redundant long-HPD events after modesetting. It is used for affected EIZO and BenQ displays.

The HKC G27H7Pro needs the same EDID-specific flag.

File:

src/common/displayport/src/dp_wardatabase.cpp

Required case:

// HKC
case 0x6321:
    if (ProductID == 0x2723)
    {
        this->WARFlags.ignoreRedundantHotplug = true;
        DP_PRINTF(DP_NOTICE, "DP-WAR> HKC G27H7Pro redundant hotplug");
    }
    break;

The values are in the byte order returned by the driver’s existing EDID accessors:

ManufacturerID: 0x6321
ProductID:      0x2723

With this flag, ConnectorImpl::notifyLongPulse(true) recognizes that the display was already connected and returns before redundant link reassessment is performed.

The fix does not suppress:

• initial display detection;
• first connection;
• real unplug events;
• real plug events;
• suspend/resume device reconstruction;
• normal link training;
• 3840x2160@160 operation;
• HBR3 x4;
• DSC or FEC.

It only prevents a verified healthy link from being retrained in response to a redundant plug event from this exact display model.

Validation

The patched NVIDIA kernel modules were tested with:

1. A cold boot followed by login.
2. A complete user logout.
3. Plasma Login greeter startup.
4. Authentication into a newly created Plasma Wayland session.

In both tests:

external display: operational
mode: 3840x2160@160
internal display: operational
periodic freezes: absent
sleep/resume recovery: no longer required

The redundant RM callbacks still occurred during display handoff, proving that the event producer was unchanged. DPLib reported:

previous_plugged=1
connected=1
ignore=1
active_rate=810
active_lanes=4
assessed_rate=810
assessed_lanes=4

After ignore=1 was applied, the callback no longer initiated the repeating link-assessment/training loop. No subsequent periodic HBR3 training or atomic stalls occurred.

In local validation, the bug is completely fixed by adding this EDID-specific case.

To Reproduce

see above

Bug Incidence

Always

nvidia-bug-report.log.gz

nvidia-bug-report.log.gz

More Info

No response

Start in src/common/displayport/src/dp_wardatabase.cpp and compare the existing EIZO and BenQ redundant-hotplug workarounds with the EDID values reported for the HKC G27H7Pro. Build the open kernel modules and repeat cold-login and logout/login validation; done means the external 3840x2160@160 display remains operational without periodic freezes.