Guilgo Blog

El 25 de octubre el panel de un ASUS TUF Gaming A16 se quedó en negro al entrar en Plasma. La sesión no estaba muerta. spectacle escribió un PNG de 1920×1200 con el escritorio entero. KWin había compuesto ese frame. El panel no lo presentó.

Esa captura demuestra que la ruta de composición y de captura seguía viva. No demuestra que el framebuffer destinado al scanout fuera válido. La imagen volvió en la misma sesión, después de un modeset a 60 Hz y un ciclo DPMS aplicados uno detrás del otro. La causa no está cerrada. NVIDIA 615.78.08 es el módulo abierto que cargaba linux-cachyos 7.3.0-5 ese día. En la misma tarde también cambió la revisión de empaquetado de KWin, y por la mañana habían entrado firmware y Mesa. El número del módulo es parte del incidente, pero no hay evidencia suficiente para señalar a NVIDIA como causa raíz.

Tres pantallas negras que no son la misma

Con el panel a oscuras se mezclan tres fallos distintos. La captura los separa.

Este caso es el tercero. Vale para cualquier equipo, no solo para este TUF. kscreen-doctor veía eDP-2 connected, enabled, DPMS On y brillo al 100 %. El compositor tenía un frame de 1920×1200. El panel no lo enseñaba.

Qué devolvió la imagen

Con el panel en negro, los comandos se pueden lanzar desde una terminal que ya estuviera abierta en la sesión de Plasma, o en remoto contra esa misma sesión gráfica. SSH y una consola virtual (Ctrl+Alt+F3) también valen, siempre que lleguen al D-Bus del usuario: kscreen-doctor habla con Plasma, no con el kernel. En las notas de este incidente no quedó qué vía usé.

eDP-2 es el nombre del conector en este portátil. En otro equipo hay que leerlo antes de copiar los comandos:

kscreen-doctor -o

El modo activo era el preferido del panel, 1920×1200@165 con VRR Automatic. Lo bajé a 60 Hz, quité el VRR y, sin mirar el panel entre una orden y la siguiente, forcé un ciclo DPMS:

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

Ahí volvió la imagen. Las dos acciones fueron seguidas, así que no sé si la recuperó el modeset, el ciclo DPMS o la combinación. En otro equipo las separaría: primero 60 Hz y VRR Never, y el ciclo DPMS solo si el panel sigue negro.

Con el panel ya visible restituí los 165 Hz y dejé el VRR apagado:

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

Ese segundo cambio no repitió Failed to create framebuffer. Se quedó en 1920×1200@165, VRR Never, escala 1.05, durante el resto de la sesión.

KWin guardó el modo en ~/.config/kwinoutputconfig.json. El reloj del modo pasó de 446160 a 162240 al bajar a 60 Hz, y volvió a 446160 al restituir los 165 Hz. Esos números no son hercios. Son el pixel clock del modo, en kHz. El cociente 446160/162240 es exactamente 165/60: el reloj acompaña al refresco, no lo sustituye.

No doy por cerrado que el culpable sea solo los 165 Hz. El error de framebuffer fue al crear la sesión, con 165 Hz y VRR Automatic. Lo comprobado es más estrecho: un modeset a 60 Hz junto con un ciclo DPMS sacó imagen, y los 165 Hz aguantaron después, en esa sesión, con VRR en Never. Falta el arranque siguiente con solo ese cambio, sin la variable de KWin del final.

El equipo

ASUS TUF Gaming A16, placa FA608UM. Gráficos híbridos ATPX: el panel interno lo conduce la iGPU. asusd 6.5.0, gpu_mux_mode en 1, dgpu_disable en 0.

Qué cambió en los paquetes

CachyOS, con paquetes *.1 / znver4 donde aplica. El mismo día hubo dos tandas. La pantalla negra aparece con la de la tarde, y esa tanda mueve varias piezas a la vez.

23 de octubre de 2026, 07:26 (CEST). El equipo siguió usándose después, todavía con el kernel 7.3.0-4, sin este fallo. Firmware y Mesa ya estaban actualizados en ese uso.

lib32-mesa se quedó en 3:26.2.4-1. La tanda de la mañana, por sí sola y con el kernel 7.3.0-4, no dejó el panel en negro. Esos paquetes seguían instalados cuando arrancó 7.3.0-5.

23 de octubre de 2026, 20:58 (CEST). Primer arranque del kernel nuevo a las 23:37. A partir de ahí, en cada boot de esta sesión de diagnóstico.

KWin cambió de revisión de empaquetado, no de versión upstream. plasma-desktop y plasma-workspace siguen en 6.8.1-1.1. Wayland sigue en 1.26.0-1.1.

El módulo abierto que carga el kernel se identifica así:

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

Userspace ya estaba en nvidia-utils 615.78.08-2, lib32-nvidia-utils 615.78.08-1 y nvidia-settings 615.78.08-1. El cambio de esa tarde, en el lado NVIDIA, es el módulo empaquetado en linux-cachyos-nvidia-open 7.3.0-5, no un salto dentro de la rama 615. Llegó en el mismo upgrade que el kernel 7.3.0-5 y que la revisión de KWin. No los separé. Un error NVRM en el journal no basta para atribuirle el panel negro.

La línea de arranque no se tocó. Ya llevaba amdgpu.dcdebugmask=0x10:

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

Qué dicen los logs

En el arranque, KWin registra dos veces:

kwin_wayland: Failed to create framebuffer: Invalid argument

Ese mensaje indica un fallo al crear un framebuffer DRM. Por sí solo no demuestra un fallo de reserva de memoria. Puede venir de KWin, del kernel, de un driver o de una combinación de modo. No dice, por sí solo, que KWin estuviera intentando el scanout del panel interno por la RTX.

En el greeter, un arranque antes:

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

Tampoco establecen esa relación. Son un fallo de permisos en el greeter, en otro arranque.

La RTX, en el boot del panel negro:

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

En este híbrido ATPX el panel interno está en la 780M. La RTX no tiene CRTC sobre ese panel. Los conectores que enumera (card1-eDP-1, card1-DP-1, card1-HDMI-A-1) salen disconnected, con EDID de 0 bytes. El panel está en card2-eDP-2 (pci-0000:65:00.0-card). Los números card1 y card2 cambian entre boots. El by-path no.

amdgpu no registra su backlight de Display Core porque ya existe otro:

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

El backlight presente es nvidia_wmi_ec_backlight (firmware, 200/200, bl_power 0). Es el mecanismo con el que este equipo controla el brillo. No lo tomo como conflicto confirmado entre los dos drivers, ni como explicación del panel negro.

No hubo panic, oops, Xid ni OOM. Quedaban unos 25 GiB de RAM libres. El disco no mostraba actividad rara.

Detalle aparte, por si alguien llega aquí buscando la otra línea del kernel: desde el primer boot de 7.3.0-5 escribe una vez por arranque clocksource: Watchdog remote CPU N read timed out. El reloj sigue siendo tsc y no lo marcó inestable. En la sesión corta anterior, con 7.3.0-4, esa línea no salió. No hay evidencia que relacione ese aviso con la pantalla negra.

Lo comprobado y lo pendiente

La prueba que más información puede dar es la que falta en el medio: reiniciar con VRR Never y sin KWIN_DRM_DEVICES. El script de entorno de más abajo ya está en disco, así que Plasma exportaría la variable en el siguiente login gráfico. Hay que apartar kwin-drm.sh, o comentar el export, antes de ese reinicio. Si el panel enciende, la hipótesis del orden de las GPU pierde fuerza. Si vuelve a quedar negro, hay una pista más concreta antes de volver a poner la variable.

KWIN_DRM_DEVICES, todavía sin validar

Dejé preparado, para el próximo login, que KWin abra solo el dispositivo DRM de la 780M. Los números cardN cambian entre boots. El by-path no. El archivo es ~/.config/plasma-workspace/env/kwin-drm.sh:

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

Plasma lee ese directorio al entrar en la sesión de usuario. Para la prueba de reinicio de arriba, el archivo tiene que estar fuera de ese directorio; si no, la prueba ya no es «sin la variable». KWIN_DRM_DEVICES restringe qué dispositivos DRM abre KWin. No es una preferencia de GPU. En este portátil los conectores que enumera la RTX quedarían fuera de esa lista. No he comprobado, tras un login nuevo, ni las salidas externas ni si el offload por el render node sigue funcionando. El script no cubre el greeter.

En esta sesión no reinicié KWin. La variable no está validada. Tampoco demuestra que el orden de enumeración de las GPU fuera la causa del fallo.

Recuperación confirmada; causa raíz pendiente

La imagen volvió. El incidente no está cerrado.

Sigue abierto:

• El módulo 615.78.08 no lee temperatura ni power mode del SBIOS de este FA608UM. Sale en cada arranque de 7.3.0-5.
• El HDMI de la RTX no tiene EDID. Un Lenovo que este equipo tenía memorizado en HDMI-A-1 no aparece.
• drmModeListLessees(): Permission denied en el greeter.
• El aviso del clocksource watchdog en 7.3.0-5, sin marcar el TSC inestable. No hay evidencia que lo relacione con el panel negro.
• El próximo arranque con VRR Never y sin KWIN_DRM_DEVICES, después de apartar kwin-drm.sh.
• Después, si hace falta, un login con la variable, mirando salidas externas y offload.

Si te pasa en otro TUF con 780M + RTX 50 y el mismo conjunto de paquetes, el atajo empírico es el kscreen-doctor de arriba, con el nombre de salida de tu equipo. Devuelve la imagen en este hardware. No nombra al culpable.

Para comparar tu equipo

Estos comandos sirven para poner otro sistema al lado de este. kscreen-doctor tiene que ejecutarse donde vea el D-Bus de la sesión de Plasma.

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'

Compara los PCI ID y el nombre de la salida (eDP-2 aquí) antes de copiar un modeset. Los números card1 y card2 son la comparación débil: cambian entre boots.