Solución de problemas

NVIDIA EGL/dmabuf, tema del cursor, peculiaridades anidado bajo Hyprland, compartir pantalla y el env del portal, latencia de lanzamiento — lo que más molesta al principio.

Soluciones prácticas para las cosas que de verdad surgen. En caso de duda, lee primero el registro de la sesión: una sesión real redirige stderr a $XDG_STATE_HOME/atlaswm/session.log (~/.local/state/atlaswm/session.log, más .old para la ejecución anterior). Activa debug { trace #true } para obtener una traza de acciones cuando un atajo se porte mal.

NVIDIA

El backend DRM de atlaswm se desarrolla y se usa a diario en una GeForce RTX 3080 (Ampere) con los módulos de kernel abiertos nvidia-open — ese camino funciona en esa tarjeta exacta. Algunas cosas que conviene saber:

EGL lo proporciona el driver del sistema. El EGL de NVIDIA viene de /run/opengl-driver (la ruta del driver en NixOS) vía GLVND; la sesión no necesita envoltura de nixGL. nvidia-drm.modeset=1 debe estar activado — ya lo está si ejecutas hoy cualquier compositor de Wayland.

dmabuf + explicit sync van juntos. atlaswm anuncia zwp_linux_dmabuf_v1 junto con wp_linux_drm_syncobj_manager_v1 (explicit sync). En NVIDIA estos van en pareja: el egl-wayland de NVIDIA lee su dispositivo de renderizado del global de dmabuf y luego toma el camino de dmabuf + explicit-sync — anunciar dmabuf sin explicit sync hace que la inicialización de EGL del cliente NVIDIA falle con EGL_BAD_ALLOC / "failed to allocate resources", y los clientes GL (kitty, …) no arranquen. atlaswm incluye ambos, así que esto está resuelto; figura aquí porque si alguna vez ves esos errores de asignación de EGL en session.log, esta es el área a revisar.

Advertencias benignas. Las advertencias MESA-LOADER / libEGL … fd -1 son el cargador de Mesa sondeando y fallando antes de que el EGL de NVIDIA tenga éxito — son ruido, no un fallo. La advertencia Unable to become drm master bajo logind también es benigna (solo controla el traspaso de master al cambiar de VT; un kernel moderno concede el modeset).

Un congelamiento total de la GPU suele ser un fallo de firmware, no de atlaswm. Una pantalla congelada que requiere reiniciar en este hardware ha sido un fallo de firmware de la GPU NVIDIA (Xid 62, parada del GSP/PMU), no un error del compositor. atlaswm tiene resiliencia ante cuelgues de GPU: un fallo de renderizado sostenido te devuelve limpiamente a tu greeter en unos ~5 s (con un error claro en session.log) en lugar de mantener una sesión congelada y rota en silencio. No puede desatascar la GPU — eso requiere reiniciar — pero no te quedarás ante una pantalla negra preguntándote qué pasa.

El cursor parece una simple flecha de X

El backend DRM dibuja su propio cursor y carga el tema XCursor de XCURSOR_THEME / XCURSOR_SIZE. Si te sale la flecha por defecto, fija esas variables de entorno a tu tema (p. ej. un cursor de catppuccin) en el entorno de tu sesión. (El backend anidado deja que el anfitrión dibuje el cursor, así que esto solo afecta a la sesión real.)

Anidado bajo Hyprland (y otros anfitriones)

Ejecutar anidado es el camino de desarrollo, con un par de peculiaridades:

  • Mod es Alt en anidado. mod "auto" se resuelve como Alt mientras está anidado para que nunca pelee con los atajos de Super del anfitrión. Si un atajo parece muerto, comprueba si el compositor anfitrión capturó esa combinación primero.
  • Algunos atajos del anfitrión ganan. Una combinación que el compositor anfitrión tiene asignada globalmente puede no llegar nunca a atlaswm. Elige atajos que el anfitrión no use, o prueba los que entran en conflicto en una sesión real.
  • Distribución de teclado. En anidado se sigue XKB_DEFAULT_LAYOUT hasta que fijas input { xkb-layout "fr" } en la configuración. No pruebes atajos azerty con suposiciones de qwerty a secas.

Compartir pantalla

atlaswm captura la pantalla vía wlr-screencopy (los caminos de shm y de dmabuf sin copia, con la exclusión del cursor respetada). Para el flujo de desktop-portal (Google Meet, Discord, captura PipeWire de OBS), se apoya en xdg-desktop-portal-wlr (xdpw), que se encarga del portal de D-Bus, el selector y el flujo de PipeWire.

Instala y enruta xdpw (NixOS):

xdg.portal.wlr.enable = true;
xdg.portal.config.atlaswm."org.freedesktop.impl.portal.ScreenCast" = [ "wlr" ];

El truco del entorno de activación. xdg-desktop-portal lo arranca D-Bus/systemd con su propio entorno. Para que el portal enrute ScreenCast al backend wlr debe ver XDG_CURRENT_DESKTOP=atlaswm en ese entorno — y en una sesión real atlaswm lo empuja allí (dbus-update-activation-environment), exactamente como hacen las sesiones de sway/Hyprland. Si una compartición sigue fallando con "must be authorized to share your screen" incluso después de permitirla, lo más probable es que la interfaz ScreenCast no se expusiera porque ese env no estaba puesto — asegúrate de estar en una sesión recién reconstruida (un compositor en ejecución obsoleto de antes de una reconstrucción es el culpable habitual; vuelve a iniciar sesión, o reinicia si reiniciar la sesión no lo mata).

Dos monitores. La captura de monitor completo funciona; el selector del portal (un selector slurp/dmenu vía xdpw) elige qué monitor.

Si xdpw no arranca con Compositor supports neither ext_image_copy_capture or wlr_screencopy!, necesita tanto zwlr_screencopy_manager_v1 como zwp_linux_dmabuf_v1 — atlaswm anuncia ambos, así que esto apunta a un binario viejo; limpia el fallo de systemd con systemctl --user reset-failed xdg-desktop-portal-wlr y vuelve a iniciar sesión en la build actual.

Las herramientas que te puedes lanzar tú mismo confirman el camino de forma independiente: grim (salida completa y región -g "x,y wxh"), grim -o DP-1 (un monitor) y wf-recorder capturan todos fotogramas con la orientación correcta.

Los clientes GL tardan en arrancar

Un retraso notable al abrir cada cliente GL (un terminal, un navegador) en NVIDIA es el sondeo de EGL de Mesa fallando antes de que el EGL de NVIDIA tenga éxito (~300 ms/cliente). Es cosmético — el cliente sí arranca. (Se probó un pin de glvnd que se salta el sondeo de Mesa y se revirtió porque rompía EGL tras una reconstrucción empaquetada; es una compensación conocida, no un error que arreglar en la configuración.)

Un cambio de configuración no se aplicó

La configuración se recarga en vivo menos de un segundo después de guardarla — si se analiza correctamente. Un error tipográfico, un verbo desconocido o una regex rota hacen que toda la recarga falle, el error queda registrado y la configuración anterior sigue ejecutándose. Así que si un cambio parece ignorado, revisa session.log (o ejecuta atlasctl default-config para confirmar la sintaxis exacta) — probablemente tengas un error de análisis manteniendo viva la última configuración válida. Corrige y guarda para volver a aplicar.

Problemas con apps de XWayland

atlaswm ejecuta apps X11 (Steam, Discord, toolkits antiguos) vía XWayland — sin configuración extra. echo $DISPLAY en un terminal debería imprimir :N. Las ventanas X11 tiladas ignoran el mover/redimensionar del lado del cliente (el diseño es dueño de la geometría tilada, igual que en Wayland); hazlas flotantes (Mod+space o una regla float #true) para arrastrarlas/redimensionarlas libremente. Las superficies override-redirect (algunos menús/tooltips) se posicionan con el mejor esfuerzo posible cuando el plano está paneado/con zoom.