[Bug] Suspend/Resume: External displays fail (Quadro T1000) - "Permission denied (os error 13)" and Xwayland desync

[iqivi]

Symptom
On a laptop with a Quadro T1000, suspending the system with external monitors connected (1x USB-C 4K ThinkVision, 1x HDMI FHD BenQ) results in black screens upon resume. While the kernel detects the displays as connected, the compositor fails to re-initialize the DRM device or sync with Xwayland.

Environment

OS: Pop!_OS (COSMIC Alpha/Epoch)

Compositor: cosmic-comp

GPU: NVIDIA Quadro T1000 (Driver: 580.119.02)

Displays: ThinkVision 4K (USB-C/DP-Alt), BenQ FHD (HDMI)

The Logs (Journalctl)
The failure begins during the suspend phase where the compositor loses DRM master permissions:
Plaintext

cosmic-comp[1586]: Failed to submit rendering: Failed to submit result for display
cosmic-comp[1586]: Unable to clear state: DRM access error: Failed to commit on clear_state on device Some("/dev/dri/card0") (Permission denied (os error 13))

Upon resume, the compositor fails to re-acquire the device and Xwayland falls out of sync:
Plaintext

cosmic-comp[1586]: Failed to set xwayland primary output: The provided output wasn't known to Xwayland
cosmic-comp[1586]: Failed to resume drm device
cosmic-comp[1586]: Failed to update drm device /dev/dri/card1.
cosmic-comp[1586]: Failed to destroy old mode property blob: No such file or directory (os error 2)
cosmic-comp[1586]: Error while handling udev event.

Diagnostic Details

Post-resume, cat /sys/class/drm/card*-*/status confirms the kernel sees the hardware as connected.

Manual udevadm trigger --subsystem-match=drm --action=change does not recover the displays but triggers the xwayland primary output error in cosmic-comp.

Replugging cables does not resolve the issue; only a full reboot or restarting the display manager/session works.

Steps to Reproduce

Connect 4K USB-C and FHD HDMI monitors.

Enter suspend mode.

Resume. External displays remain black/no signal.

[iqivi]

I can add that changing in BIOS Graphics from Hybrid to Discrete fixed this issue. It also fixed sluggish UI on external 4k display.

[mikemhenry]

I think I have another reproduction of this, with one additional finding: after the failed resume, cosmic-comp appears to have persisted bad display state in outputs.ron, so a reboot alone did not recover the external monitor.

System:

• Pop!_OS 24.04 / COSMIC
• hybrid Intel + NVIDIA laptop
• NVIDIA GeForce RTX 2060 Mobile
• NVIDIA proprietary driver 580.173.02
• kernel 7.0.11-76070011-generic
• cosmic-comp 0.1~1785355703~24.04~091583a
• external ASUS VS248, 1920x1080@60, connected via USB-C hub / DisplayPort

Sequence I observed:

1. The system resumed from suspend with the USB-C hub/external monitor connected.

2. The kernel successfully detected the external display; /sys/class/drm/card0-DP-1/status reported connected.

3. Around the resume, cosmic-comp began producing the same class of DRM errors reported here, including:

   • Failed to resume drm device
   • DRM/modesetting Permission denied (os error 13)
   • Failed to destroy old mode property blob
   • failures resetting/applying the output configuration

4. The NVIDIA driver also logged:
   Invalid request parameters, planePitch or rmObjectSizeInBytes, passed during surface registration

5. COSMIC Display Settings showed the external monitor, but it was disabled.

6. Trying to enable it in Display Settings caused the graphical session/compositor to become unusable; Wayland applications began reporting broken pipes. SSH remained responsive.

7. I rebooted. After the reboot, the machine itself was healthy, but the external monitor was still disabled/no-signal.

8. I backed up and deleted ~/.local/state/cosmic-comp/outputs.ron, then rebooted again.

9. The external monitor immediately worked normally again with the same hub, cable, and monitor.

The saved outputs.ron from the broken state is interesting.

It contained the normal two-monitor topology with the external DP monitor explicitly stored as:

enabled: r#false

It also contained a separate topology key in which the same internal display appeared twice:

[
    (
        connector: "eDP-1",
        make: "LG Display",
        model: "0x0625",
    ),
    (
        connector: "eDP-1",
        make: "LG Display",
        model: "0x0625",
    ),
]: [
    ...
]

After deleting outputs.ron and allowing cosmic-comp to regenerate it, that duplicate-eDP-1 topology disappeared and the external display works normally again.

I'm attaching the before/after outputs.ron files and their diff.

I don't know whether the duplicate topology is a cause or simply persisted fallout from the failed DRM resume. However, it looks like the resume failure can leave output state behind that survives a reboot and prevents the external display from recovering.

This also seems related to #1040, where deleting outputs.ron recovered a session broken following suspend/external-display changes. The underlying Permission denied behavior may also relate to #2078.

The especially notable difference from the original report here is that a normal reboot was not sufficient recovery in my case; deleting the persisted output configuration was required.

outputs-ron-diff-20260810.txt
outputs-rons-before-after-20260810.txt