¿Por fin podremos usar Wayland en 2026?

• Wayland es la pila gráfica sucesora de X11, iniciada en 2008, pero el autor considera que no pudo usarla correctamente en su sistema durante 18 años
• Para 2025, con el soporte de GBM y explicit sync en los drivers de nVidia, ya es posible arrancarlo de forma básica, pero una transición completa sigue siendo difícil por problemas como la falta de soporte para TILE en monitores 8K
• Hubo avances técnicos importantes en Sway 1.11 y wlroots 0.19.0, pero aún existen muchos obstáculos de uso real, como latencia de entrada, glitches gráficos y problemas de escalado en Xwayland
• Aplicaciones clave como Chrome y Emacs siguen mostrando problemas de rendimiento, diferencias de renderizado e inestabilidad en la aceleración por hardware
• En general, Wayland “por fin empieza a verse viable para uso real”, pero para el trabajo diario la combinación X11/i3 sigue siendo más estable

---

Contexto histórico de Wayland

• Wayland es un proyecto sucesor del servidor X (X11, Xorg) iniciado en 2008, y el autor desarrolló en 2009 el gestor de ventanas en mosaico i3 para X11
• Al principio solo se podía ejecutar el compositor de demostración Weston, y luego GNOME en 2014 y más tarde KDE empezaron a dar soporte a Wayland
• Aplicaciones importantes como Firefox, Chrome y Emacs solo podían usar Wayland mediante flags experimentales
• Las GPU de nVidia durante mucho tiempo no funcionaban en Wayland o provocaban errores gráficos, y además persistieron los problemas de compatibilidad con monitores 8K
• Recientemente, distribuciones importantes como Fedora, RHEL y Asahi Linux adoptaron Wayland como pila de escritorio predeterminada o incluso única, aumentando la presión para migrar

Configuración del entorno de ejecución de Wayland

• El sistema de prueba usó una nVidia RTX 4070 Ti (PC del laboratorio) y una RTX 3060 Ti (PC principal)
• Desde el driver nVidia 495 (2021) se agregó soporte para GBM, y la función explicit sync fue implementada en Sway 1.11 (2025) y wlroots 0.19.0
• Sin embargo, por la falta de soporte para la propiedad TILE del monitor 8K Dell UP3218K, en Sway la pantalla aparece dividida en dos
  • Mediante un parche de EBADBEEF y el análisis de Claude Code, se descubrió un bug en la propiedad DRM SRC_X, y con un parche temporal se logró mostrar la pantalla completa
• GNOME sí soporta TILE, pero aparece un tearing severo en el centro de la pantalla
• En un entorno NixOS 25.11, se configuraron en paralelo GDM, GNOME y Sway, y se añadieron herramientas exclusivas de Wayland como foot, fuzzel y wayland-utils

Resultados del experimento: entorno Sway

• Sway es compatible en gran parte con la configuración de i3, y el autor ajustó la distribución de teclado NEO y la configuración de entrada y salida
• Problemas principales:
  • Retraso en el puntero del mouse y movimiento poco fluido (se sospecha falta de soporte de cursor por hardware en nVidia)
  • Imposibilidad de escalar apps de Xwayland, por lo que se ven borrosas o con doble ampliación
  • Algunos atajos se ejecutan dos veces (ghost key press)
• En apps GTK, el problema inicial de tamaño excesivo de fuente se resolvió con gsettings reset
• Como GTK3 solo usa configuración de dconf, hay que definir font-name en dconf para que el renderizado coincida
• swaylock, a diferencia de i3lock, al cerrarse queda en estado de “pantalla roja” y solo puede liberarse con SIGUSR1
• Las herramientas de automatización basadas en i3 IPC tienen compatibilidad parcial por diferencias en la ruta del socket, procesos residuales y falta de soporte para restaurar layouts

Pruebas con aplicaciones principales

• El terminal foot es ligero, pero se detectaron algunas diferencias de color, manejo de Ctrl+Enter, selección de URL y problemas de color con screen
• Emacs en su versión predeterminada corre bajo Xwayland y se ve borroso, mientras que la versión pgtk presenta retraso de entrada y diferencias en el espaciado entre caracteres
• Chrome pierde la aceleración por hardware debido a fallos del proceso GPU, y al restaurar ventanas no conserva la información del workspace anterior
• El screen sharing funciona mediante xdg-desktop-portal-wlr, pero existen problemas como falta de soporte para compartir por ventana y transmisión en baja resolución
• Al activar el escalado de salida, aparecen glitches donde el contenido de las ventanas se desplaza momentáneamente o se vuelve borroso
• Las notificaciones de dunst y rofi (2.0.0 o superior) funcionan correctamente, mientras que la herramienta de capturas grim resulta incómoda para seleccionar ventanas

Conclusión: posibilidades de usar Wayland en 2026

• La sesión Wayland/Sway por primera vez se acerca a un nivel utilizable en la práctica, pero aún persisten numerosos defectos
• El entorno X11/i3 ofrece baja latencia de entrada del orden de 763μs y estabilidad total
• Al migrar a Wayland aparecen glitches gráficos, latencia de entrada y degradación del rendimiento en aplicaciones clave
• Condiciones necesarias para el uso diario:
  • Resolver en Sway la doble entrada de teclas y los glitches al cambiar
  • Estabilizar la aceleración por hardware de Chrome y dar soporte a la restauración de ventanas
  • Mejorar la latencia de entrada y el renderizado de Emacs (pgtk)
• En conclusión, Wayland todavía no está listo para el trabajo diario, y el autor planea seguir usando X11/i3

[GN⁺]

Comentarios en Hacker News

• Wayland es simplemente un protocolo, así que existen varias implementaciones (GNOME, KDE, wlroots, etc.)
  Xorg tenía una estructura donde el escritorio se montaba sobre una sola base sólida, pero en Wayland cada escritorio termina reinventando la rueda.
  Weston sirve como referencia, pero no es adecuado para el uso diario.
  Creo que hace falta una biblioteca estándar que todos los escritorios puedan usar en común. wlroots apunta a cumplir ese rol, pero no parece que GNOME o KDE vayan a migrar pronto
  • Creo que X.org encontró el nivel de abstracción adecuado. El WM no tenía que manejar directamente la entrada ni la salida, y gracias a eso había simplicidad y buena eficiencia energética. Wayland no aprendió las lecciones de X11
  • He usado Sway, Hyprland y ahora niri. Sway y niri, basados en wlroots, están bastante bien, pero todavía tienen muchos bugs aleatorios. Problemas con el puntero en apps de Wine, fallos al compartir pantalla, problemas con color de 10 bits, etc. Tal vez para 2027 esté estable, pero para 20 años de desarrollo se siente ineficiente
  • KDE y GNOME tienen cada uno su propia implementación de xdg-desktop-portal, lo que causa problemas de compatibilidad. Si usas wlroots, necesitas xdg-desktop-portal-wlr; si usas Hyprland, xdg-desktop-portal-hyprland.
    La estructura de Wayland en sí, como muestra la documentación oficial de arquitectura, se ve bien en teoría, pero en la práctica faltan muchas cosas a nivel de protocolo
  • En realidad X también era un protocolo, pero como existía una implementación única llamada X.org, había menos confusión. No es técnicamente imposible tener una biblioteca estandarizada al nivel de wlroots
  • Los desarrolladores de Wayland lo diseñaron originalmente como un protocolo solo para pantalla. Esperaban que otro grupo hiciera los protocolos de entrada o de gestión de ventanas, pero eso no salió bien.
    Los intentos actuales de reemplazar Wayland podrían terminar siendo un desperdicio al volver a crear partes que ya estaban maduras
• Todavía no entiendo por qué habría que usar Wayland. Xorg es estable, y la mayoría de las guías para resolver problemas empiezan con “si usas Wayland, vuelve a Xorg”.
  Probablemente la adopción aumente de verdad solo cuando las distribuciones lo impongan por defecto, como pasó con systemd
  • El usuario común no tiene una razón clara para cambiar. Aun así, Wayland maneja bien cosas en las que X11 flojea, como el escalado en múltiples pantallas.
    Desde la perspectiva de GNOME y KDE, buena parte del impulso hacia Wayland viene de querer reducir la carga de seguir manteniendo X11.
    Creo que la meta este año es llegar a un punto donde “no tenga desventajas”
  • Wayland da la sensación de ofrecer un rendimiento más fluido, pero por algunas apps todavía tengo que usar Xorg.
    Arch y Ubuntu ya quitaron Xorg de la opción predeterminada en GNOME 49, y KDE probablemente siga pronto. La era de Xorg se está acabando
  • Antes había que editar xorg.conf a mano, pero después de probar Wayland de forma experimental en Ubuntu me cambié por completo. Supongo que por usar una GPU AMD, todo va fluido y sin problemas
  • La ventaja de Wayland es el fractional scaling
  • Yo necesito herramientas como x2x, xev y xdotool, pero por el modelo de seguridad de Wayland eso no es posible, así que sigo en Xorg
• Es un malentendido decir que Nvidia rechazó la API GBM de Wayland. GBM era una API no oficial interna de Mesa, así que Nvidia no podía implementarla por su cuenta.
  Por eso propuso una alternativa neutral frente a proveedores llamada EGLStreams.
  Más bien, el problema fue que del lado de freedesktop no ofrecieron una estructura en la que el driver de Nvidia pudiera funcionar
  • Aun así, me pregunto cómo un proyecto open source como Mesa puede depender de una API privada
• Llevo años usando Wayland en Gnome y no he tenido ningún problema.
  Claro, quizá ayuda que no uso Nvidia y tengo hardware sencillo, pero quiero recalcar que Wayland sí puede funcionar bien
  • A mí igual, en Sway (2016) y KDE Plasma 6 me funciona perfecto. Solo corro juegos de Steam con XWayland. La combinación AMD/Intel es mucho más estable
  • Incluso con hardware Nvidia últimamente funciona bastante fluido. Antes iba a tirones, pero ahora siento que va mejor que Xorg.
    Eso sí, cosas como controlar la posición de las ventanas o explorar otras apps todavía requieren rodeos con extensiones de Gnome Shell
  • Como esa anécdota de la gente que antes no notaba el parpadeo de los monitores CRT, pequeñas molestias como la sensación de entrada o las diferencias de fuente en Wayland pueden percibirse distinto según la persona
• Llevo años usando Wayland basado en wlroots/swaywm y hasta la eGPU funciona perfecto.
  Aunque quizá sea porque uso hardware AMD. La vida es demasiado corta para desperdiciarla en problemas de Nvidia
  • En cambio, con gráficos integrados Intel sway se me crashea seguido, así que volví a i3+Xorg
  • Llevo 23 años usando Nvidia y no he tenido grandes problemas. Aun así, creo que es cuestión de elección personal
  • Antes también lo usaba bien con Nvidia, y con el parche TILE hasta una pantalla 5K iba bastante bien.
    Me pasé a Wayland por el soporte de escalado en múltiples salidas y luego volví atrás
• Hace poco me pasé a Linux por los problemas recientes de Windows, y antes era imposible por la falta de fractional scaling.
  Wayland resolvió eso y ha sido una gran mejora. Aun así, no todas las distribuciones usan Wayland por defecto, así que elegí Ubuntu.
  El Firefox en Snap no usaba aceleración por hardware, así que fue un poco molesto
  • Para mí también lo que más le falta a Linux es el fractional scaling.
    En MacOS, incluso si configuras que “se vea como 1440p”, queda perfecto, y en Windows se ve un poco borroso.
    En Linux, X11 es lento y Wayland todavía tiene latencia de rendimiento
• Yo también uso la combinación i3+NixOS+urxvt+zsh+Emacs+rofi+maim+xdotool.
  Cambiar este stack que funciona perfecto por Sway tendría más desventajas que ventajas.
  Me parece admirable que Michael lo haya intentado y documentado
  • Me impresionó lo bien que registró los problemas reales con tanto detalle
• No pienso cambiarme hasta que el window manager (WM) que uso soporte Wayland.
  El mayor problema de Wayland es que muchos proyectos de WM no pueden hacer la transición por falta de gente.
  Se puede sortear con XWayland, pero no quiero agregar otra capa a un entorno que ya funciona perfecto
  • Si usas StumpWM, su versión para Wayland, Mahogany, está en desarrollo activo.
    Además, Wayback es un proyecto para ejecutar un escritorio completo de X11 sobre Wayland
• Uso Wayland en una laptop Framework y funciona perfecto.
  Monitor 4K, cambio a una sola pantalla, fractional scaling: todo sin problemas.
  Incluso en un Chromebook viejo desapareció el screen tearing y funciona suave.
  Todavía no le encuentro desventajas; de hecho, la única es escuchar que “está mal” usarlo
  • Qué bueno si te funciona bien, pero también hay que reconocer que hay gente a la que no le funciona
  • Que hayas tenido suerte y no te hayas topado con problemas no significa que no existan desventajas
• Para mí Wayland tiene solo desventajas y ninguna ventaja. Creo que está mal planteado eso de empujar la complejidad a otras capas.
  Voy a seguir usando Xorg y Openbox
  • Distribuir la complejidad de un solo lugar a varios fue una decisión incomprensible
  • Aun así, el mantenimiento de Xorg está disminuyendo y los desarrolladores principales se están moviendo a Wayland.
    Al final, Wayland será la única opción que sigue recibiendo mantenimiento activo