Guilgo Blog

On 25 October the internal panel of an ASUS TUF Gaming A16 went black as Plasma came up. The session was not dead. Spectacle wrote a 1920×1200 PNG of the full desktop. KWin had composited that frame. The panel did not present it.

The capture shows that compositing and screen capture were still alive. It does not show that the framebuffer meant for scanout was valid. The image came back in the same session, after a modeset to 60 Hz and a DPMS cycle run back to back. The cause is still open. NVIDIA 615.78.08 is the open kernel module linux-cachyos 7.3.0-5 loaded that day. The same evening also moved KWin’s packaging revision, and firmware plus Mesa had landed that morning. The module version is part of the incident, but there is not enough evidence to identify NVIDIA as the root cause.

Three black screens that are not the same failure

A dark panel covers three different failures. A capture splits them apart.

This case is the third. It applies to any machine, not only this TUF. kscreen-doctor reported eDP-2 connected, enabled, DPMS On, brightness at 100%. The compositor held a 1920×1200 frame. The panel did not show it.

What brought the image back

With the panel black, the commands can be run from a terminal already open in the Plasma session, or remotely against that same graphical session. SSH and a virtual console (Ctrl+Alt+F3) are also options, provided they can reach the user’s D-Bus session: kscreen-doctor talks to Plasma, not to the kernel. The notes for this incident do not record which path I used.

eDP-2 is the connector name on this laptop. On another machine, read it before copying the commands:

kscreen-doctor -o

The active mode was the panel’s preferred one, 1920×1200@165 with VRR set to Automatic. I dropped it to 60 Hz, turned VRR off, and, without looking at the panel between commands, forced a DPMS cycle:

kscreen-doctor output.eDP-2.mode.1920x1200@60 output.eDP-2.vrrpolicy.never
kscreen-doctor --dpms off
sleep 1
kscreen-doctor --dpms on

The image came back. The two actions ran back to back, so I do not know whether the modeset, the DPMS cycle, or the combination did it. On another machine I would split them: 60 Hz and VRR Never first, and a DPMS cycle only if the panel is still black.

With the panel visible again I restored 165 Hz and left VRR off:

kscreen-doctor output.eDP-2.mode.1920x1200@165 output.eDP-2.vrrpolicy.never

That second modeset did not repeat Failed to create framebuffer. The output stayed at 1920×1200@165, VRR Never, scale 1.05, for the rest of the session.

KWin stored the mode in ~/.config/kwinoutputconfig.json. The mode clock went from 446160 to 162240 at 60 Hz, and back to 446160 when 165 Hz was restored. Those figures are not hertz. They are the mode’s pixel clock, in kHz. 446160/162240 is exactly 165/60: the clock tracks the refresh rate. It does not replace it.

I am not calling 165 Hz the sole cause. The framebuffer error happened when the session was created, at 165 Hz with VRR Automatic. What is checked is narrower: a modeset to 60 Hz together with a DPMS cycle produced an image, and 165 Hz held afterwards, in that session, with VRR set to Never. The next boot with only that change, and without the KWin variable at the end of this post, has not been done.

The machine

ASUS TUF Gaming A16, board FA608UM. ATPX hybrid graphics: the iGPU drives the internal panel. asusd 6.5.0, gpu_mux_mode set to 1, dgpu_disable set to 0.

What changed in the packages

CachyOS, with *.1 / znver4 packages where that applies. Two upgrades on the same day. The black panel starts with the evening one, and that upgrade moves several pieces at once.

23 October 2026, 07:26 CEST. The machine kept being used afterwards, still on kernel 7.3.0-4, without this failure. Firmware and Mesa were already updated during that use.

lib32-mesa stayed at 3:26.2.4-1. The morning batch, on its own and with kernel 7.3.0-4, did not blank the panel. Those packages were still installed when 7.3.0-5 booted.

23 October 2026, 20:58 CEST. First boot of the new kernel at 23:37. Every boot of this diagnosis after that.

KWin moved a packaging revision, not an upstream version. plasma-desktop and plasma-workspace stayed at 6.8.1-1.1. Wayland stayed at 1.26.0-1.1.

The open module the kernel loads identifies itself like this:

NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64  615.78.08
Release Build  Fri Oct 23 15:27:35 UTC 2026

Userspace was already on nvidia-utils 615.78.08-2, lib32-nvidia-utils 615.78.08-1, and nvidia-settings 615.78.08-1. On the NVIDIA side, the evening change is the module shipped in linux-cachyos-nvidia-open 7.3.0-5, not a jump inside the 615 branch. It landed in the same upgrade as kernel 7.3.0-5 and the KWin packaging revision. I did not separate them. An NVRM line in the journal is not enough to blame the module for the black panel.

The kernel command line was left alone. It already carried amdgpu.dcdebugmask=0x10:

quiet nowatchdog splash rw rootflags=subvol=/@ amdgpu.dcdebugmask=0x10

What the logs actually say

At startup KWin logs this twice:

kwin_wayland: Failed to create framebuffer: Invalid argument

That indicates a failure while creating a DRM framebuffer. It does not, by itself, mean a memory allocation failure. It can come from KWin, the kernel, a driver, or a mode combination. On its own it does not say that KWin was trying to scan the internal panel out through the RTX.

On the greeter, one boot earlier:

kwin_wayland: drmModeListLessees() failed: Permission denied
kwin_wayland: Applying output configuration failed: EACCESS
kwin_wayland: Failed to find a working output layer configuration: EACCESS

Those lines do not establish that link either. They are a permission failure on the greeter, from another boot.

The RTX, on the black-panel boot:

NVRM: failed to get target temp from SBIOS
      platform_request_handler_ctrl.c:2175
      NV_ERR_INVALID_DATA (0x00000025)
NVRM: failed to get platform power mode from SBIOS
      platform_request_handler_ctrl.c:2118
nvidia-modeset: Unable to read EDID for display device DP-0
nvidia 0000:01:00.0: [drm] Cannot find any crtc or sizes

On this ATPX hybrid the internal panel sits on the 780M. The RTX has no CRTC on that panel. The connectors it enumerates (card1-eDP-1, card1-DP-1, card1-HDMI-A-1) come up disconnected, with a 0-byte EDID. The panel is on card2-eDP-2 (pci-0000:65:00.0-card). The card1 and card2 numbers swap between boots. The by-path name does not.

amdgpu skips its Display Core backlight because another one already exists:

amdgpu 0000:65:00.0: [drm] Skipping amdgpu DM backlight registration

The backlight that is present is nvidia_wmi_ec_backlight (firmware, 200/200, bl_power 0). That is how this machine controls brightness. I am not treating it as a confirmed conflict between the two drivers, or as the explanation of the black panel.

No panic, no oops, no Xid, no OOM. About 25 GiB of RAM still free. The disk was not busy.

A separate line, for anyone who lands here chasing it: from the first 7.3.0-5 boot the kernel prints clocksource: Watchdog remote CPU N read timed out once per boot. The clocksource stays tsc. It was not marked unstable. The short previous session on 7.3.0-4 did not print it. There is no evidence linking this warning to the black screen.

Checked, and still open

The check that would tell the most is the one in the middle: reboot with VRR Never and without KWIN_DRM_DEVICES. The env script further down is already on disk, so Plasma would export the variable on the next graphical login. Move kwin-drm.sh aside, or comment out the export, before that reboot. If the panel lights up, the GPU-order hypothesis gets weaker. If it goes black again, there is a sharper lead before putting the variable back.

KWIN_DRM_DEVICES, not validated yet

For the next login I left KWin set to open only the 780M DRM device. The cardN numbers change between boots. The by-path name does not. The file is ~/.config/plasma-workspace/env/kwin-drm.sh:

#!/bin/sh
export KWIN_DRM_DEVICES=/dev/dri/by-path/pci-0000:65:00.0-card

Plasma reads that directory when the user session starts. Leave the file out of that directory for the reboot test above, or the test is no longer “without the variable”. KWIN_DRM_DEVICES restricts which DRM devices KWin opens. It is not a GPU preference. On this laptop the connectors the RTX enumerates would fall outside that list. I have not checked, after a new login, either the external outputs or whether render-node offload still works. The script does not cover the greeter.

I did not restart KWin in this session. The variable is not validated. It also does not show that GPU enumeration order caused the failure.

Image restored; root cause still open

The image came back. The incident is not closed.

Still open:

• Module 615.78.08 cannot read target temperature or platform power mode from this FA608UM SBIOS. It prints on every 7.3.0-5 boot.
• The RTX HDMI connector has no EDID. A Lenovo display this machine had remembered on HDMI-A-1 no longer shows up.
• drmModeListLessees(): Permission denied on the greeter.
• The clocksource watchdog warning on 7.3.0-5, with TSC left stable. There is no evidence linking it to the black panel.
• The next boot with VRR Never and without KWIN_DRM_DEVICES, after moving kwin-drm.sh aside.
• After that, if it is still needed, a login with the variable, checking external outputs and offload.

On another TUF with a 780M and an RTX 50, running the same package set, the empirical shortcut is the kscreen-doctor sequence above, using your own output name. On this hardware it brings the image back. It does not name the culprit.

Compare your machine

These are the commands that line another system up with this one. kscreen-doctor has to run where it can see the Plasma session’s D-Bus.

uname -r
lspci -nn -d 1002:
lspci -nn -d 10de:
kscreen-doctor -o
journalctl --user -b --no-pager _COMM=kwin_wayland
journalctl -b -k --no-pager | grep -E 'NVRM|amdgpu|nvidia'

Match PCI IDs and the output name (eDP-2 here) before copying a modeset. The card1 / card2 numbers are the weak comparison: they swap between boots.