Hace unos meses tomé la decisión de migrar mi sesión de Qtile de X11 a Wayland. No fue una decisión de un día para el otro, ni la típica "vamos a ver qué pasa si cambio el backend". Venía siguiendo el desarrollo de Qtile 0.36+ con soporte nativo de Wayland via wlroots, y sabía que eventualmente iba a dar el salto. La pregunta no era si iba a migrar, sino cómo hacerlo para que no duela.

Spoiler: no dolió tanto. Y no fue porque sea un genio de la configuración, sino porque desde el principio armé mi entorno pensando que algún día iba a tener que convivir con los dos backends.

La decisión: por qué Wayland

No me movía una necesidad urgente. X11 funcionaba bien. Picom con blur se veía genial, Flameshot para capturas, todo andaba. Pero había cosas que me molestaban cada vez más: el tearing en video, la falta de soporte nativo de HDR, la imposibilidad de tener fracciones de escala en monitores mixtos. Y sobre todo, el hecho de que X11 es un protocolo que tiene cuarenta años y se nota. Wayland no es perfecto, pero es el futuro y todos los proyectos grandes se están moviendo para allá.

Además, Qtile ya tenía soporte Wayland estable. Si mi window manager lo bancaba, no había excusa para no probarlo.

La jugada maestra: dual-backend desde el día uno

Cuando armé mis dotfiles, hace tiempo, tomé una decisión que después me salvaría: todo lo que no dependiera del backend lo separé. Los keybindings, los grupos, los layouts, las screens — todo eso vive en archivos compartidos que Qtile carga igual en X11 que en Wayland. Lo único que cambia es el autostart y algunos componentes específicos: 

X11:                          Wayland:
  Polybar  (barra)              Waybar   (barra)
  Picom    (compositor)         wlroots  (compositor nativo)
  Nitrogen (wallpaper)          Qtile   (wallpaper nativo)
  Flameshot (screenshots)       grim+slurp (screenshots)
  betterlockscreen (lock)       swaylock (lock)
  xrandr   (monitores)          wlr-randr (monitores)

El autostart detecta automáticamente qué backend está corriendo con una línea de Python y arranca los componentes correspondientes: 

is_wayland = 'WAYLAND_DISPLAY' in os.environ

if is_wayland:
    # Arrancar Waybar, grim+slurp, swaylock
else:
    # Arrancar Polybar, Picom, Nitrogen, Flameshot

La belleza de esto es que ambas configuraciones conviven. No tengo que elegir un backend definitivo. Si un día necesito X11, selecciono "Qtile" en LightDM. Si quiero Wayland, selecciono "Qtile (Wayland)". Los dos comparten la misma base de configuración y el mismo sistema de temas.

Lo que sí salió mal (y cómo lo resolví)

No todo fue color de rosas. Varias cosas se rompieron en el camino:

  • Waybar no aparecía al arrancar. Resulta que el autostart no estaba disparando el launch.sh de Waybar. Una boludez, pero me comí un rato hasta darme cuenta de que el hook de Wayland estaba mal configurado.
  • El wallpaper no se veía. En X11 usaba Nitrogen, que obviamente no funciona en Wayland. Tuve que configurar el wallpaper desde Qtile directo con Screen(wallpaper=...).
  • Flameshot dejó de funcionar. No es compatible con Wayland. Lo reemplacé por grim + slurp, que terminó siendo incluso más rápido para mi flujo de trabajo.
  • Rofi no arrancaba. Hasta que me acordé de que necesitaba la versión 2.0+ para Wayland. Una vez actualizado, anduvo de diez.

Cada uno de estos errores los fui resolviendo con ayuda de opencode. De hecho, fue durante esta migración que nació la idea de crear el agente arch-sysadmin. Me di cuenta de que estaba repitiendo el mismo patrón una y otra vez: diagnosticar un problema de configuración, buscar la solución, aplicarla, y después no acordarme de cómo lo había resuelto si volvía a pasar. Necesitaba un contexto permanente que entendiera mi sistema, mis rutas, mis herramientas. Un agente que supiera de entrada que uso Qtile, que tengo dual-backend, que mi gestor de paquetes es yay, que mi editor es Neovim. Ese agente se convirtió en arch-sysadmin, y hoy es mi interfaz principal para todo lo que tenga que ver con mantener el sistema.

El estado actual

Hoy vivo el 80% del tiempo en Wayland. Vuelvo a X11 solo cuando necesito algo muy específico que todavía no tiene equivalente en Wayland (rara vez pasa). La experiencia es prácticamente idéntica porque el sistema de temas es el mismo, los keybindings son los mismos, los scripts son los mismos — lo único que cambia es lo que está debajo.

El proyecto completo está documentado en mis dotfiles, incluyendo la arquitectura de la migración, los componentes por backend, los scripts de detección, y la tabla de resolución de problemas.

Si hay una lección que me llevo de esta migración es: diseñá tu sistema pensando en que algún día vas a querer cambiarlo. La modularidad no es un lujo, es el mejor seguro contra el pánico de "no sé por dónde arrancar".

Wayland no es perfecto, pero está mucho más maduro de lo que la gente cree. Y con un window manager que lo soporte bien, como Qtile, la migración es más cuestión de ordenar componentes que de reescribir configuraciones enteras. Si estás pensando en migrar, mi recomendación es: primero hacé que ambos backends convivan, después apagá X11. No al revés.