Arch Linux

Santo C01

Member

Registered: 2026-03-02

Posts: 20

Intermittent SDDM black screen after NVIDIA update — QSGRenderThread s

Hi,

I'm troubleshooting an intermittent SDDM/multi-monitor black-screen problem on Arch Linux with NVIDIA.

The problem started around Thursday. Before that, this multi-monitor setup had been operating normally.

Relevant setup:

- Arch Linux
- KDE Plasma
- Plasma session: Wayland
- SDDM: X11
- SDDM theme: Breeze
- NVIDIA open kernel modules
- nvidia-open 615.71.09-3
- nvidia-utils 615.71.09-1
- linux 7.2.6.arch2-1
- linux-lts 6.18.52-1
- Three-monitor setup
- One monitor is an ASUS XG27UCG with dual-mode functionality

Timeline:

On Thursday I performed a normal Arch system update. That update included a new NVIDIA driver.

Later that same day, after playing CS2, I switched the ASUS XG27UCG using its dual-mode function (4K <-> 1080p/high-refresh mode).

Immediately after changing the monitor mode, all three monitors went black.

The system subsequently reported NVIDIA DRM errors similar to:

[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR*
[nvidia-drm] [GPU ID ...] Flip event timeout on head 0

I initially treated this as a runtime display/mode-switching issue.

Since that day, however, I have also started seeing intermittent problems while the displays are being initialized during boot/SDDM.

The behavior is not consistent between boots.

On one boot, SDDM appeared but monitor detection seemed unusually slow.

On another boot, all monitors remained black when SDDM should have appeared. The computer itself had NOT frozen. Ctrl+Alt+F3 successfully switched to a TTY and I could log in and use the system normally from there.

On the next successful boot, SDDM appeared, but one monitor remained black at the login screen. As soon as I logged into the Plasma Wayland session, that monitor initialized and operated normally.

This made me investigate SDDM separately from Plasma.

During the boot where all monitors remained black, I captured the failure from the TTY.

sddm-greeter-qt6 had crashed:

PID: 1327 (sddm-greeter-qt)
TID: 1372 (QSGRenderThread)
UID: 963 (sddm)
Signal: 11 (SEGV) si_code: SEGV_MAPERR
Command Line: /usr/bin/sddm-greeter-qt6 [...] --theme /usr/share/sddm/themes/breeze
Executable: /usr/bin/sddm-greeter-qt6

The relevant part of the crashing QSGRenderThread stack is:

Stack trace of thread 1372:

#0  n/a (libnvidia-glcore.so.615.71.09 + 0xb2f1f5)
#1  n/a (libnvidia-glcore.so.615.71.09 + 0x7e73c0)
#2  n/a (libnvidia-glcore.so.615.71.09 + 0x7e8941)
#3  n/a (libnvidia-glcore.so.615.71.09 + 0x7e8b34)
#4  n/a (libQt6Gui.so.6 + 0x5e21c3)
#5  n/a (libQt6Gui.so.6 + 0x5e6f07)
#6  n/a (libQt6Gui.so.6 + 0x5dd3bf)
#7  QRhi::endFrame(...) (libQt6Gui.so.6 + 0x42d0a7)
#8  n/a (libQt6Quick.so.6 + 0x4c2eb8)

The SDDM greeter stack also contains the XCB/X11 Qt platform components:

libQt6XcbQpa.so.6
libxcb.so.1
xcb_wait_for_event

I then checked my SDDM configuration.

There is no custom DisplayServer override in /etc/sddm.conf or /etc/sddm.conf.d/.

The packaged SDDM configuration currently contains:

[General]
DisplayServer=x11

[Wayland]
CompositorCommand=weston --shell=kiosk
SessionCommand=/usr/share/sddm/scripts/wayland-session

[X11]
SessionCommand=/usr/share/sddm/scripts/Xsession

Therefore Plasma is running Wayland after login, while the SDDM greeter itself is running through X11/XCB.

I also found other Arch forum discussions suggesting early NVIDIA KMS as something to check for SDDM startup/display initialization problems.

However, my /etc/mkinitcpio.conf already contains:

MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)

So the NVIDIA modules are already explicitly included in the initramfs.

I have not yet:

- switched SDDM from X11 to Wayland
- added an artificial delay before SDDM starts
- downgraded the NVIDIA driver
- changed the NVIDIA initramfs configuration

I wanted to collect evidence from an actual failed boot before changing the configuration.

The system is currently able to boot and run Plasma normally. On a successful boot I have no NVIDIA errors at journal priority 3, no priority 2 errors, and systemctl --failed reports zero failed units.

The timing is what makes me suspicious:

Thursday:
Arch update including new NVIDIA driver
    ->
CS2
    ->
ASUS dual-mode switch
    ->
all monitors black
    ->
NVIDIA DRM flip-event timeout

Following boots:
intermittent monitor initialization problems
    ->
one completely black SDDM boot
    ->
TTY still functional
    ->
sddm-greeter-qt6 QSGRenderThread SIGSEGV
    ->
stack trace enters libnvidia-glcore.so.615.71.09

I don't want to assume that the NVIDIA update, the dual-mode/flip-timeout incident, and the later SDDM crash necessarily have the same underlying cause, but the timing seemed relevant enough to include.

Does this look more like:

1. SDDM starting before the NVIDIA/multi-monitor stack is completely ready,
2. an NVIDIA/Qt6 rendering issue affecting the X11 SDDM greeter,
3. or a display initialization/race issue related to the current NVIDIA driver?

Since early NVIDIA KMS is already configured, would delaying SDDM be a reasonable diagnostic step?

Would testing SDDM under Wayland be useful, or would it be better to leave the current configuration unchanged until the cause is better established?

Also, could the earlier NVIDIA DRM flip-event timeout triggered by the monitor's dual-mode switch be relevant to the later SDDM failures?

I can provide additional journal output, package versions, SDDM logs, or boot timing information if needed.

Thanks.