Dépannage

NVIDIA EGL/dmabuf, thème de curseur, particularités en imbriqué sous Hyprland, partage d'écran et l'env du portail, latence de lancement — ce qui coince en premier.

Des correctifs pratiques pour les choses qui surviennent réellement. En cas de doute, lisez d'abord le journal de session : une vraie session redirige stderr vers $XDG_STATE_HOME/atlaswm/session.log (~/.local/state/atlaswm/session.log, plus .old pour l'exécution précédente). Activez debug { trace #true } pour une trace d'actions quand un raccourci se comporte mal.

NVIDIA

Le backend DRM d'atlaswm est développé et utilisé au quotidien sur une GeForce RTX 3080 (Ampere) avec les modules noyau ouverts nvidia-open — ce chemin fonctionne sur cette carte précise. Quelques points à connaître :

EGL est fourni par le pilote système. L'EGL de NVIDIA provient de /run/opengl-driver (le chemin du pilote NixOS) via GLVND ; la session n'a besoin d'aucun enveloppage nixGL. nvidia-drm.modeset=1 doit être activé — il l'est déjà si vous exécutez un compositor Wayland quelconque aujourd'hui.

dmabuf + explicit sync vont de pair. atlaswm annonce zwp_linux_dmabuf_v1 conjointement à wp_linux_drm_syncobj_manager_v1 (explicit sync). Sur NVIDIA, ils forment une paire : l'egl-wayland de NVIDIA lit son périphérique de rendu depuis le global dmabuf puis emprunte le chemin dmabuf + explicit-sync — annoncer dmabuf sans explicit sync fait échouer l'initialisation EGL des clients NVIDIA avec EGL_BAD_ALLOC / "failed to allocate resources", et les clients GL (kitty, …) ne démarrent pas. atlaswm fournit les deux, c'est donc géré ; c'est listé ici car si vous voyez un jour ces erreurs d'allocation EGL dans session.log, c'est le domaine à examiner.

Avertissements bénins. Les avertissements MESA-LOADER / libEGL … fd -1 sont le chargeur de Mesa qui sonde et échoue avant que l'EGL de NVIDIA ne réussisse — ce sont du bruit, pas un échec. L'avertissement Unable to become drm master sous logind est lui aussi bénin (il ne gouverne que le transfert de master au changement de VT ; un noyau moderne accorde le modeset).

Un gel franc du GPU est généralement une faute du firmware, pas atlaswm. Un écran gelé qui nécessite un redémarrage sur ce matériel a été une faute du firmware du GPU NVIDIA (Xid 62, arrêt GSP/PMU), pas un bug du compositor. atlaswm dispose d'une résilience aux blocages GPU : un échec de rendu prolongé vous ramène proprement à votre greeter en ~5 s (avec une erreur claire dans session.log) au lieu de maintenir une session silencieusement cassée et gelée. Il ne peut pas débloquer le GPU — cela demande un redémarrage — mais vous ne resterez pas devant un écran noir à vous interroger.

Le curseur ressemble à une simple flèche X

Le backend DRM dessine son propre curseur et charge le thème XCursor depuis XCURSOR_THEME / XCURSOR_SIZE. Si vous obtenez la flèche par défaut, réglez ces variables d'environnement sur votre thème (p. ex. un curseur catppuccin) dans l'environnement de votre session. (Le backend imbriqué laisse l'hôte dessiner le curseur, cela n'affecte donc que la vraie session.)

En imbriqué sous Hyprland (et autres hôtes)

L'exécution en imbriqué est le chemin de développement, avec quelques particularités :

  • Mod est Alt en imbriqué. mod "auto" se résout en Alt en imbriqué pour ne jamais entrer en conflit avec les raccourcis Super de l'hôte. Si un raccourci semble inactif, vérifiez si le compositor hôte a capté cet accord en premier.
  • Certains raccourcis de l'hôte l'emportent. Un accord que le compositor hôte a lié globalement peut ne jamais atteindre atlaswm. Choisissez des raccourcis que l'hôte n'utilise pas, ou testez ceux en conflit dans une vraie session.
  • Disposition clavier. L'imbriqué suit XKB_DEFAULT_LAYOUT jusqu'à ce que vous définissiez input { xkb-layout "fr" } dans la configuration. Ne testez pas des raccourcis azerty avec des suppositions de qwerty nu.

Partage d'écran

atlaswm capture l'écran via wlr-screencopy (chemins shm et dmabuf zéro-copie, exclusion du curseur honorée). Pour le flux desktop-portal (Google Meet, Discord, capture OBS PipeWire), il s'appuie sur xdg-desktop-portal-wlr (xdpw), qui assure le portail D-Bus, le sélecteur et le flux PipeWire.

Installer et router xdpw (NixOS) :

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

Le piège de l'environnement d'activation. xdg-desktop-portal est démarré par D-Bus/systemd avec son propre environnement. Pour que le portail route ScreenCast vers le backend wlr, il doit voir XDG_CURRENT_DESKTOP=atlaswm dans cet environnement — et sur une vraie session atlaswm l'y pousse (dbus-update-activation-environment), exactement comme le font les sessions sway/Hyprland. Si un partage échoue toujours avec « must be authorized to share your screen » même après l'avoir autorisé, c'est probablement que l'interface ScreenCast n'a pas été exposée parce que cet env n'était pas réglé — assurez-vous d'être sur une session fraîchement reconstruite (un compositor encore en cours d'avant une reconstruction est le coupable habituel ; reconnectez-vous, ou redémarrez si la reconnexion ne le tue pas).

Deux moniteurs. La capture plein moniteur fonctionne ; le sélecteur du portail (un sélecteur slurp/dmenu via xdpw) choisit quel moniteur.

Si xdpw ne démarre pas avec Compositor supports neither ext_image_copy_capture or wlr_screencopy!, il lui faut à la fois zwlr_screencopy_manager_v1 et zwp_linux_dmabuf_v1 — atlaswm annonce les deux, cela pointe donc vers un ancien binaire ; effacez l'échec systemd avec systemctl --user reset-failed xdg-desktop-portal-wlr et reconnectez-vous dans la version actuelle.

Des outils que l'on pilote soi-même confirment le chemin indépendamment : grim (plein écran et région -g "x,y wxh"), grim -o DP-1 (un seul moniteur), et wf-recorder capturent tous des images correctement orientées.

Les clients GL sont lents à démarrer

Un délai notable à l'ouverture de chaque client GL (un terminal, un navigateur) sur NVIDIA est la sonde EGL de Mesa qui échoue avant que l'EGL de NVIDIA ne réussisse (~300 ms/client). C'est cosmétique — le client démarre bel et bien. (Un épinglage glvnd qui saute la sonde Mesa a été essayé puis annulé car il cassait l'EGL après une reconstruction groupée ; c'est un compromis connu, pas un bug à corriger dans la configuration.)

Un changement de configuration ne s'est pas appliqué

La configuration est rechargée à chaud dans la seconde qui suit l'enregistrement — si elle s'analyse. Une coquille, un verbe inconnu ou une regex cassée fait échouer tout le rechargement, l'erreur est consignée, et la configuration précédente continue de s'exécuter. Donc si un changement semble ignoré, consultez session.log (ou exécutez atlasctl default-config pour confirmer la syntaxe exacte) — vous avez probablement une erreur d'analyse qui maintient en vie la dernière configuration valide. Corrigez et enregistrez pour réappliquer.

Problèmes d'applications XWayland

atlaswm exécute les applications X11 (Steam, Discord, anciens toolkits) via XWayland — sans configuration supplémentaire. echo $DISPLAY dans un terminal devrait afficher :N. Les fenêtres X11 tuilées ignorent le déplacement/redimensionnement côté client (la disposition possède la géométrie tuilée, comme pour Wayland) ; rendez-les flottantes (Mod+space ou une règle float #true) pour les déplacer/redimensionner librement. Les surfaces override-redirect (certains menus / infobulles) sont positionnées au mieux quand le plan est en panoramique/zoom.