HDMI output unrecoverable after udev hotplug event — atomic commits stuck in page-flip loop

[djmittens]

Description

After a udev-triggered hotplug event on an HDMI-connected LG TV, the HDMI output becomes permanently stuck. Aquamarine detects the disconnect and reconnect correctly, re-enumerates modes, allocates new swapchain buffers, and attempts to modeset — but every atomic commit fails with Cannot commit when a page-flip is awaiting. The output never recovers. Only a full compositor restart fixes it.

The hotplug is not physical — no cable was touched. The NVIDIA driver emits a udev change event on /dev/dri/card0, likely triggered by the TV toggling the HPD pin internally. This worked fine on the previous driver/compositor combination (NVIDIA 580.119.02 + Hyprland 0.52.2 + aquamarine 0.9.4).

Sequence of events from logs

1. System is running normally, HDMI-A-1 modesetting at 2560x1440@120Hz
2. udev: new udev change event for card0 — no physical interaction
3. Aquamarine scans connectors, HDMI-A-1 reports connection state: 2 (disconnected)
4. drm: Connector HDMI-A-1 disconnected / drm: Disabling output HDMI-A-1 — CRTC 61 removed
5. Second udev change event — still disconnected, CRTC removed again
6. Third udev change event — connector reports connection state: 1 (connected)
7. Aquamarine reconnects HDMI-A-1, assigns CRTC 61, dumps modes, detects VRR/HDR capabilities
8. Swapchain cleared, new buffers allocated:
   • XR30 allocation fails: GBM: Failed to allocate a GBM buffer: format XR30 isn't supported by primary backend
   • Falls back to XB30 successfully
9. drm: Modesetting HDMI-A-1 with 2560x1440@120.00Hz
10. drm: Cannot commit when a page-flip is awaiting — every subsequent commit fails with this error
11. Output is permanently stuck. hyprctl keyword monitor changes, DPMS toggles, disable/re-enable all fail because no atomic commit can go through.

Note: The XR30 allocation failure also occurs for the DP-2 (7680x2160) output, but DP-2 recovers fine by falling back to XB30. The issue is specifically that the HDMI atomic commit pipeline gets wedged after the hotplug reconnect.

Key observations

• The first hotplug cycle early in the session (at boot) shows the same disconnect/reconnect pattern and recovers successfully. The second cycle later in the session does not recover — suggesting some state isn't being properly reset between hotplug events.
• hyprctl keyword monitor "HDMI-A-1,disable" followed by re-enable does not clear the stuck state.
• DPMS off/on does not clear the stuck state.
• The DP-2 output on the same GPU continues working fine throughout.

System info

Hyprland 0.53.3 (commit dd220efe7b1e)
Aquamarine 0.10.0
NVIDIA GeForce RTX 5090 (GB202)
NVIDIA UNIX Open Kernel Module 590.48.01
Manjaro Linux, kernel 6.12.68-1-MANJARO

Monitors:
- DP-2: Samsung Odyssey G95NC 7680x2160@240Hz (works fine)
- HDMI-A-1: LG TV 2560x1440@120Hz (broken after hotplug)

Previous working configuration

• NVIDIA 580.119.02
• Hyprland 0.52.2
• Aquamarine 0.9.4

All upgraded simultaneously on Jan 8, 2026, so the regression could be in aquamarine 0.10.0, Hyprland 0.53, or an interaction with the NVIDIA 590 driver. The aquamarine 0.10.0 change "Ensure disconnect called for removed connectors" (#215) modified connector disconnect handling and may be relevant.

Relevant log excerpt

udev: new udev change event for card0
drm: Got a hotplug event for /dev/dri/card0
drm: Connector 127 connection state: 2
drm: Connector HDMI-A-1 disconnected
drm: Disabling output HDMI-A-1
drm: Connector HDMI-A-1 is not connected, removing old crtc 61
...
[second hotplug — reconnects]
drm: Connector HDMI-A-1 connected
drm: Connecting connector HDMI-A-1, CRTC ID 61
drm: Modesetting HDMI-A-1 with 2560x1440@120.00Hz
ERR: GBM: Failed to allocate a GBM buffer: format XR30 isn't supported by primary backend
[falls back to XB30 — OK]
drm: Modesetting HDMI-A-1 with 2560x1440@120.00Hz
ERR: drm: Cannot commit when a page-flip is awaiting
drm: Modesetting HDMI-A-1 with 2560x1440@120.00Hz
ERR: drm: Cannot commit when a page-flip is awaiting
drm: Modesetting HDMI-A-1 with 2560x1440@120.00Hz
ERR: drm: Cannot commit when a page-flip is awaiting
[repeats indefinitely — output never recovers]

[djmittens]

Possible root cause: stale isPageFlipPending across disconnect/reconnect

After reading through the code, I think there may be a race condition where isPageFlipPending isn't cleared in time during a hotplug disconnect/reconnect cycle. I'm not certain this is the full picture, but the code path seems suspicious enough to share.

The scenario (as I understand it)

1. HDMI output is displaying normally. An atomic commit was submitted with DRM_MODE_PAGE_FLIP_EVENT, so connector->isPageFlipPending is true (set in CDRMAtomicImpl::commit(), Atomic.cpp:466), waiting for the kernel page-flip completion event.

2. HPD event fires, recheckOutputs() → scanConnectors() sees the connector as disconnected → conn->disconnect() is called.

3. disconnect() (DRM.cpp:1597) emits output->events.destroy, calls output.reset(), sets status = DRM_MODE_DISCONNECTED. But it doesn't clear isPageFlipPending.

4. The CDRMOutput destructor (DRM.cpp:1668) does clear isPageFlipPending = false, but only when the shared pointer refcount hits zero. If the compositor still holds a reference to the output (which Hyprland likely does — it processes the destroy signal asynchronously), the destructor doesn't run immediately.

5. The TV reconnects quickly (HPD bounces back). connect() creates a new CDRMOutput, sets up the swapchain, calls scheduleFrame().

6. scheduleFrame() (DRM.cpp:2054) checks connector->isPageFlipPending — still true from the old, not-yet-destructed output. Frame isn't scheduled.

7. When Hyprland tries to modeset, commitState() (DRM.cpp:1775) checks connector->isPageFlipPending — still true. Returns "Cannot commit when a page-flip is awaiting". Every subsequent commit also fails.

8. Eventually the old page-flip event arrives from KMS and handlePF() clears the flag — but by then the compositor may have already given up retrying, or the CRTC state is inconsistent because handlePF() bails early at line 997 if the connector state looks wrong.

This would explain why the first hotplug cycle (early in session, possibly no in-flight page-flip) succeeds but the second one (mid-session, page-flip likely in-flight) gets stuck.

Possible fix

Clear isPageFlipPending and frameEventScheduled in disconnect() immediately, rather than relying on the CDRMOutput destructor which may fire later:

void Aquamarine::SDRMConnector::disconnect() {
    if (!output) {
        backend->backend->log(AQ_LOG_DEBUG, std::format("drm: Not disconnecting connector {} because it's already disconnected", szName));
        return;
    }

    // Clear page-flip state now rather than waiting for CDRMOutput destructor,
    // which may run later if the compositor still holds a reference to the output.
    // Without this, a quick reconnect can see stale isPageFlipPending=true and
    // get stuck in "Cannot commit when a page-flip is awaiting".
    isPageFlipPending = false;
    frameEventScheduled = false;

    output->events.destroy.emit();
    output.reset();

    status = DRM_MODE_DISCONNECTED;
}

And possibly also at the top of connect() as a safety net:

void Aquamarine::SDRMConnector::connect(drmModeConnector* connector) {
    if (output) {
        backend->backend->log(AQ_LOG_DEBUG, std::format("drm: Not connecting connector {} because it's already connected", szName));
        return;
    }

    // Ensure clean state from any previous connection
    isPageFlipPending = false;
    frameEventScheduled = false;

    // ... rest of connect()

How to verify

I haven't been able to test this — the bug requires a specific HPD-bouncing TV and the timing is race-dependent. Some ideas:

1. Add logging: Add a backend->log() in disconnect() that prints isPageFlipPending and frameEventScheduled at the moment of disconnect. If the theory is right, the failing case would show isPageFlipPending=true at disconnect time. Same for the top of connect().

2. Check destructor timing: Add logging in CDRMOutput::~CDRMOutput() with a timestamp. Compare against the connect() log. If the destructor runs after the reconnect, that confirms the race.

3. Synthetic hotplug test: If there's a way to trigger a connector disconnect/reconnect from DRM (e.g., sysfs or a debug ioctl) while a page-flip is in-flight, that could reproduce it. Though I'm not sure how easy that is with NVIDIA's driver.

4. Just apply the patch: The change is pretty small and should be safe — it matches what the CDRMOutput destructor already does, just earlier in the lifecycle. Worst case, clearing an already-false flag is a no-op.

I could be wrong about the destructor timing being the specific trigger here — there might be something else going on with NVIDIA 590's event delivery. But the fact that disconnect() doesn't reset page-flip state while ~CDRMOutput() does seems like an oversight regardless.

[djmittens]

Update: diffed NVIDIA 580.119.02 vs 590.48.01 open kernel modules

The page-flip and hotplug code in nvidia-drm is identical between 580 and 590. Specifically: __nv_drm_handle_flip_event(), nv_drm_handle_flip_occurred(), nv_drm_event_callback(), nv_drm_handle_display_change(), flip list enqueue/dequeue, the nonblock -EBUSY check, and the blocking 3-second timeout recovery — all unchanged. nvidia-drm-encoder.c and nvidia-drm-connector.c have zero changes.

The 590 changes are unrelated cleanup: VRR semaphore removal (dead code for pre-NVDisplay GPUs), a cursor surface fix (bug 4966645), unconditional color property exposure, DRM_FORMAT_ABGR16161616 addition, and removal of pre-NVDisplay legacy codepaths. None touch page-flip or hotplug.

The missing flip_list cleanup on hotplug disconnect has always been absent in nvidia-drm — it's not a 590 regression. This narrows the regression to the aquamarine/Hyprland side.