COSMIC freezes when launching Quartus Prime through Xwayland on NVIDIA RTX 2070; DRM page-flip errors

[developer-yuryeuceda]

COSMIC freezes when launching Quartus Prime through Xwayland on NVIDIA RTX 2070; DRM page-flip errors

Environment

• OS: Pop!_OS 24.04
• Desktop: COSMIC
• Session: Wayland
• Kernel: 7.1.5-76070105-generic
• GPU: NVIDIA GeForce RTX 2070 8 GB
• NVIDIA driver: 595.84
• Xwayland: 24.1.13
• Quartus Prime: Standard Edition 25.1std.0 Build 1129
• Quartus path: ~/altera_standard/25.1std/quartus
• CPU: Intel Xeon E5-2678 v3, 12 cores / 24 threads
• RAM: ~48 GB

Relevant session variables:

XDG_SESSION_TYPE=wayland
XDG_CURRENT_DESKTOP=COSMIC
WAYLAND_DISPLAY=wayland-1
DISPLAY=:1

The user's Xwayland instance is launched by cosmic-comp:

cosmic-session
  └─ cosmic-comp
      └─ Xwayland :1

Problem

Launching Quartus Prime can cause the entire COSMIC desktop to freeze.

The compositor itself does not necessarily terminate. The system remains accessible through a TTY, and cosmic-comp remains running, but the graphical session becomes unresponsive.

The failure appears to involve the COSMIC compositor's DRM/rendering path.

The most important errors observed in the journal are:

Failed to submit rendering: Failed to submit result for display
0: The underlying drm surface encountered an error:
DRM access error: Page flip commit failed on device
Some("/dev/dri/card0")
(Permission denied (os error 13))

followed by repeated:

Unable to clear state:
DRM access error: Failed to commit on clear_state on device
Some("/dev/dri/card0")
(Permission denied (os error 13))

There are also subsequent messages such as:

Unknown X11 window associated to wl_surface in commit hook

and:

Failed to destroy old mode property blob:
No such file or directory (os error 2)

Another relevant error observed during the graphical failure is:

Failed to render texture ...:
import for wrong devices
DrmNode { dev: 57984, ty: Render }?
MultiTextureInternal { ... }
format: Some(DrmFourcc(AR24))
buffer_format: DrmFormat {
    code: DrmFourcc(AR24),
    modifier: Unrecognized(216172782120099858)
}

Reproduction

The issue is not 100% deterministic, but I can reproduce a problematic state where launching Quartus causes COSMIC to freeze.

The general sequence is:

1. Start a normal COSMIC Wayland session.
2. Xwayland is running as :1.
3. Launch Quartus Prime.
4. When the failure occurs, COSMIC becomes unresponsive.
5. Switch to a TTY with Ctrl+Alt+F3.
6. cosmic-comp is still running.
7. The journal contains the DRM page-flip and rendering errors shown above.

Quartus is using Qt/XCB rather than a native Qt Wayland backend. The Quartus installation does not contain a bundled Qt Wayland platform plugin, but it does contain the XCB plugin.

I verified that Quartus can successfully run through Xwayland.

Interesting workaround / compositor state dependency

There is an unusual and reproducible interaction with other graphical applications.

For example:

okular &

After Okular opens, I close it.

Then I launch Quartus:

cd ~/altera_standard/25.1std/quartus
./quartus

In this state, Quartus can open normally.

Importantly, Okular does not need to remain open. The sequence is:

Open Okular
    ↓
Close Okular
    ↓
Open Quartus
    ↓
Quartus works

I have observed a similar effect when creating another COSMIC terminal window before launching Quartus:

cosmic-term &

Quartus can then start successfully, and the additional terminal can subsequently be closed without causing Quartus to fail.

This makes me suspect that creating a new Wayland/COSMIC surface or triggering some compositor state transition may affect the subsequent rendering behavior.

I do not yet know what specific state is being changed.

Xwayland / NVIDIA configuration

The GPU is using the NVIDIA DRM driver:

/sys/bus/pci/drivers/nvidia

The DRM driver reports:

DRIVER=nvidia
PCI_CLASS=30000
PCI_ID=10DE:1F07

NVIDIA DRM modesetting is enabled:

nvidia-drm.modeset=1

and:

/sys/module/nvidia_drm/parameters/modeset
Y

Framebuffer device support is also enabled:

/sys/module/nvidia_drm/parameters/fbdev
Y

The NVIDIA GPU is otherwise functioning normally.

nvidia-smi reports:

NVIDIA GeForce RTX 2070
Driver Version: 595.84
Display Active: Enabled

The DRM devices are:

/dev/dri/card0
/dev/dri/renderD128

and card0 corresponds to:

pci-0000:01:00.0-card -> ../card0

DRM permissions

I initially considered whether the Permission denied messages could indicate a permissions problem.

However, the user already has explicit read/write ACLs on both DRM devices:

/dev/dri/card0
user:alex:rw-

/dev/dri/renderD128
user:alex:rw-

cosmic-comp also already has both DRM devices open.

For example:

/dev/dri/card0:
alex cosmic-comp
alex Xwayland

/dev/dri/renderD128:
alex cosmic-comp
alex Xwayland

Therefore this does not appear to be a simple filesystem permission problem.

The Permission denied appears to occur while performing the DRM page-flip/commit operation rather than while initially opening the device.

Xwayland test

I also tested Quartus against a standalone Xwayland instance rather than the COSMIC-managed Xwayland instance.

Quartus was able to create windows successfully through the standalone Xwayland/XCB setup.

The standalone Xwayland GLX environment also reported:

direct rendering: Yes
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: NVIDIA GeForce RTX 2070/PCIe/SSE2
OpenGL version: 4.6.0 NVIDIA 595.84

This suggests that the Quartus executable, bundled Qt libraries, Qt XCB plugin, and NVIDIA OpenGL stack can operate correctly outside the problematic COSMIC compositor state.

Quartus startup investigation

I also checked the Quartus launcher and environment setup.

bin/quartus is essentially a Bash wrapper which sources:

adm/qenv.sh

and then executes Quartus.

qenv.sh primarily configures:

• QUARTUS_ROOTDIR
• QUARTUS_BINDIR
• PATH
• LD_LIBRARY_PATH
• locale/runtime variables

It does not appear to explicitly configure unusual NVIDIA, DRM, or Wayland settings.

The optional:

adm/qtb.sh

does not exist in this installation, so that path is not executed.

I also verified that the Quartus bundled Qt libraries and platform plugins are present and load correctly.

Using the Qt offscreen platform allows Quartus to start successfully, confirming that the core application and bundled Qt installation are functional.

Additional observation

A similar COSMIC compositor error was observed while running a Wine game, specifically an error involving:

import for wrong devices

and an unrecognized DRM modifier.

This may indicate that the issue is not exclusively related to Quartus itself, although Quartus provides a particularly reliable trigger for reproducing the compositor failure.

Expected behavior

Launching a Qt/XCB application such as Quartus Prime should not freeze the COSMIC desktop or cause DRM page-flip failures.

Actual behavior

Under certain conditions, launching Quartus causes COSMIC to become completely unresponsive.

cosmic-comp remains running, but the journal reports DRM page-flip/commit failures and rendering/import errors.

Creating another graphical application window first can change the behavior and allow Quartus to run normally.

Possible area of investigation

I do not know whether the underlying issue is specifically:

• cosmic-comp
• Xwayland
• NVIDIA DRM/KMS
• DMA-BUF/DRM modifier handling
• an interaction between these components
• or a particular Qt/XCB surface generated by Quartus

However, the strongest evidence currently points to a problem somewhere in the:

Quartus
  ↓
Qt/XCB
  ↓
Xwayland
  ↓
cosmic-comp
  ↓
DRM/DMA-BUF/KMS
  ↓
NVIDIA DRM

path.

The cosmic-comp errors involving failed page flips, failed DRM commits, wrong-device texture imports, and unrecognized DRM modifiers seem particularly relevant.

Relevant logs

The most important messages are:

Failed to submit rendering: Failed to submit result for display

The underlying drm surface encountered an error:
DRM access error:
Page flip commit failed on device Some("/dev/dri/card0")
(Permission denied (os error 13))

Unable to clear state:
DRM access error:
Failed to commit on clear_state on device Some("/dev/dri/card0")
(Permission denied (os error 13))

Unknown X11 window associated to wl_surface in commit hook

Failed to destroy old mode property blob:
No such file or directory (os error 2)

Failed to render texture:
import for wrong devices

with an unrecognized DRM modifier.

Any guidance on what additional cosmic-comp, DRM, DMA-BUF, or Xwayland diagnostics would be useful would be appreciated.