Separación entre el compositor Wayland y el gestor de ventanas

• En el entorno Wayland tradicional, el compositor y el gestor de ventanas estaban combinados en un solo programa, pero river 0.4.0 los separa en procesos distintos
• El nuevo protocolo river-window-management-v1 otorga al gestor de ventanas control total sobre políticas como la disposición de ventanas y los atajos de teclado, mientras mantiene la perfección de fotograma (frame perfection) y el rendimiento
• Esta estructura funciona sin latencia de entrada (latency) y garantiza un renderizado limpio incluso en diseños en mosaico complejos mediante actualizaciones de estado atómicas
• Gracias a esta separación, el gestor de ventanas puede desarrollarse y reiniciarse de forma independiente, y también es más fácil implementarlo en lenguajes de alto nivel
• Este enfoque impulsa una mayor diversidad de gestores de ventanas en el ecosistema Wayland, y river ya admite más de 15 gestores compatibles

---

La estructura tradicional de Wayland y el enfoque desacoplado de river

• Los compositores Wayland tradicionales integraban en un solo proceso tres funciones: servidor de pantalla, compositor y gestor de ventanas
  • El servidor de pantalla enruta los eventos de entrada y entrega los búferes de visualización al kernel
  • El compositor combina los búferes de varias ventanas para generar la imagen final en pantalla
  • El gestor de ventanas se encarga de las políticas de usuario, como la disposición de ventanas y los atajos de teclado
• En la arquitectura X11, el servidor de pantalla existe como proceso separado, lo que provoca comunicación de ida y vuelta innecesaria y latencia
• Wayland resolvió esto al integrar el servidor y el compositor, pero no era indispensable acoplar también el gestor de ventanas
• river deshace esa unión y separa el gestor de ventanas como un programa independiente

Principios de diseño del protocolo river-window-management-v1

• Está diseñado para que el gestor de ventanas tenga el máximo control posible sin perder las ventajas de Wayland
• No requiere comunicación de ida y vuelta en cada fotograma ni en cada evento de entrada, por lo que no hay latencia de entrada
• Mantiene la perfección de fotograma (frame perfection): cuando se abre una ventana nueva o cambia de tamaño, garantiza actualizaciones de pantalla sin huecos ni superposiciones
  • El renderizado se retrasa hasta que todas las ventanas envían sus nuevos búferes, pero si se supera cierto tiempo, se maneja con un timeout
• Cuanto mejor esté implementada una aplicación, más posible será lograr una sincronización de fotogramas completamente perfecta

Estructura de gestión de ventanas basada en máquina de estados

• El protocolo divide el estado en estado de gestión de ventanas y estado de renderizado
  • Estado de gestión de ventanas: tamaño de ventana, modo de pantalla completa, foco del teclado, atajos de teclado, etc.
  • Estado de renderizado: posición de ventana, orden, decoraciones, recorte, etc.
• Los cambios se procesan agrupados como actualizaciones atómicas (manage/render sequence)
• El compositor inicia la secuencia, y cuando no hay cambios de estado, el gestor de ventanas permanece en espera
• Esta estructura formaliza de manera explícita conceptos que ya estaban implícitos en river-classic, sway y otros

Ventajas de la arquitectura desacoplada

• Los desarrolladores de gestores de ventanas pueden concentrarse solo en las políticas sin tener que implementar el compositor completo
• Es más fácil depurar y reiniciar, y un fallo del gestor de ventanas no provoca el cierre de la sesión
• Incluso si se escribe en lenguajes con recolección de basura, no hay degradación de rendimiento y funciona sin retraso de fotogramas
• Ya existen más de 15 gestores de ventanas compatibles con river, y se espera una expansión en diversidad al nivel de X11

Limitaciones y planes futuros

• Actualmente el protocolo solo admite entornos de escritorio 2D; no soporta VR ni casos similares
• Los efectos visuales complejos (por ejemplo, ventanas que se tambalean) quedan fuera de su alcance, aunque sí permite animaciones simples
• En el futuro se está evaluando soporte para shaders personalizados, aunque no es un plan a corto plazo
• river 0.4.0 ya es suficientemente usable en el día a día, y se prevén mejoras de UX antes del paso a la versión 1.0.0
• Para sostener el desarrollo, se solicitan aportes a través de liberapay, GitHub Sponsors y Ko-fi

Ejemplos y galería

• Se ofrecen ejemplos de varios gestores de ventanas que funcionan sobre river
  • Canoe: gestor de ventanas apilado clásico
  • reka: gestor de ventanas basado en Emacs
  • tarazed: entorno de escritorio centrado en el enfoque
  • rhine: gestión de ventanas recursiva y modular con soporte para animaciones
• Además de estos, existen muchos otros gestores de ventanas compatibles con river

[GN⁺]

Comentarios en Hacker News

• Me cuesta entender las quejas sobre Wayland (el protocolo) en los comentarios
  Bibliotecas como wlroots ya se encargaron de las partes pesadas, y ahora river ofrece una abstracción de más alto nivel
  El proyecto Wayland quizá pudo haber ofrecido este tipo de abstracciones antes, pero creo que era algo que cualquiera podía hacer
  Al final, estamos obteniendo estos avances gratis, así que no veo por qué quejarse de que otro no lo haga por nosotros

  • Creo que el problema empezó cuando Wayland adoptó al principio posturas de principios como prohibir capturas de pantalla
    Los temas de accesibilidad también se consideraron riesgos de seguridad, lo que complicó el diseño, y ahora que entramos en la era de la IA agéntica, esto podría volverse un punto interesante
    Pipewire ha ido cubriendo lo que Wayland dejó pendiente, pero sigue existiendo la percepción de que falta un diseño amigable para el usuario
    Aun así, creo que Wayland va dos pasos hacia adelante en el panorama general, aunque a veces dé uno o dos hacia atrás
  • Creo que la raíz del descontento está en la comunidad de Wayland, especialmente en la actitud del sector de GNOME
    Hay muchas respuestas del tipo “a mi manera o vete”, y poca flexibilidad ante solicitudes externas
    Está bien que se ofrezca gratis, pero con Xorg descontinuado y sin alternativas reales, me parece problemático imponerlo así

• Este proyecto es la primera vez que me hace sentir que Wayland no es una pérdida de tiempo
  No creo que un servidor de pantalla necesite complicarse también con la gestión de ventanas
  Supongo que la razón original por la que Wayland unió el administrador de ventanas y el compositor fue simplemente que era el camino de menor resistencia
  Aun así, el acceso remoto sigue siendo un problema. Cosas que funcionaban bien en X11 en Wayland han estado llenas de bugs

  • En X11, como el Xserver y el administrador de ventanas estaban separados, era difícil resolver problemas como la ubicación inicial de ventanas
    Wayland resolvió eso integrándolo, pero aparecieron otros efectos secundarios
  • La mayoría de los compositores pequeños de Wayland usan bibliotecas como wlroots o smithay
    Los límites de API están bien definidos, así que es fácil compartir código
    Me pregunto si el bug de rotación de 90 grados es problema del compositor o de wlroots
  • El acceso remoto en X11 era un desastre. En Wayland, en cambio, se puede estructurar de forma más limpia mediante EGL o Vulkan, así que incluso me parece mejor
  • En X11, el administrador de ventanas se encargaba de las decoraciones, así que separarlo complica la mensajería y la configuración
  • Quizá los entornos de escritorio terminaron creando sus propios ecosistemas y quitando la escalera detrás de ellos

• Creo que recién ahora se está empezando a corregir uno de los varios defectos de diseño de Wayland
  Probablemente harán falta otros 15 años para que los protocolos comunes se asienten y los administradores de ventanas maduren al nivel de X11
  Y al final, seguramente alguien volverá a decir que “va a hacer algo mejor”, descartará Wayland y empezará de cero

  • Por eso últimamente pienso que cosas como WSL o Virtualization Framework son soluciones más realistas para el escritorio Linux
    Después de sufrir con problemas de UEFI, terminé cambiándome a Samsung DEX
  • Aunque se volviera a hacer Wayland desde cero, el resultado sería parecido
    Creo que el límite no es técnico sino más bien político

• Como usuario de Linux desde hace 25 años, estoy satisfecho desde que me cambié a Wayland hace 5 años, sin problemas de screen tearing
  Para los desarrolladores habrá más trabajo, pero como usuario es una mejora clara

  • Aun así, sí extraño la función de window shading
    Me pregunto si voy a terminar hablando siempre de esto, como la gente que añoraba funciones del viejo CDE

• River ya era excelente incluso antes de esta separación. Tengo muchas ganas de ver cómo evoluciona
  Me pasé un tiempo a Niri, pero pienso volver algún día
  Si eres usuario de Xmonad, creo que River es lo que mejor te va a encajar

  • Yo también uso Xmonad, y Hyprland no manejaba bien la pila master/slave
    Me pregunto si en River las ventanas nuevas se insertan encima de la ventana actualmente seleccionada
    También me gustaría saber cómo se llamará el proyecto del lado del administrador de ventanas después de la separación

• Al final, lo que estamos haciendo es reinventar una por una las funciones de X11
  Tal vez algún día una ventana de Wayland llegue a saber dónde está ubicada

  • Los idealistas siguen evitando incluso especificar una cuadrícula virtual de píxeles 2D
    Supongo que todavía habrá que esperar bastante
  • Pero ya no importa tanto, porque hoy la mayor parte de GNU/Linux se usa en servidores sin interfaz o sistemas embebidos
    El escritorio probablemente quedará para Android, ChromeOS o máquinas virtuales sobre Windows/macOS

• Yo uso un administrador de ventanas River totalmente personalizado
  En Hyprland, por defecto solo podía usar mosaico BSP y eso me resultaba incómodo, pero en River puedo hacer el mosaico uniforme exactamente como quiero
  Esta separación cambió mucho mi flujo de trabajo

  • Si quieres “mosaico uniforme”, vale la pena revisar hy3
    Yo también fui usuario de i3, y gracias a hy3 pude usar Hyprland
  • Yo tuve un problema parecido en Hyprland y al final me cambié a Niri para tener un entorno de desarrollo estable
    Tengo mi configuración ordenada en dotfiles
  • Quiero preguntar qué significa BSP

• Según entiendo, uno de los diseños centrales de Wayland era integrar el administrador de ventanas y el compositor
  Me da curiosidad por qué se diseñó así

  • Si el administrador de ventanas es un proceso separado y se comunica de forma asíncrona, aparecen problemas de sincronización de cuadros
    Wayland lo procesó de forma síncrona para eliminar las inconsistencias visuales
  • Wayland puso todo en un solo proceso para minimizar los cambios de contexto
    Este protocolo parece ser un intento de separar el servidor gráfico y el administrador de ventanas manteniendo esa ventaja de rendimiento

• Creo que, comparado con X11, la mayor pérdida de Wayland es no poder reemplazar fácilmente el administrador de ventanas enchufable
  La gente que intenta resolver este problema de verdad es muy valiosa

  • Desde la perspectiva de alguien que ha usado el mismo administrador de ventanas durante décadas, es difícil pasarse a Wayland si no existe una interfaz de reemplazo completa
    Ojalá capas como River o Wayback puedan cumplir ese papel
  • Esta limitación también es un gran obstáculo para el desarrollo de nuevos WM y DE
    Yo también tengo ideas experimentales para escritorio, pero no me queda otra que empezar en X11, donde se puede iterar rápido
    Wayland sigue teniendo debilidades de diseño
  • En realidad, creo que bastaría con que una sola implementación ofreciera una API de extensiones de WM
    No hace falta que el estándar imponga una estructura específica
  • Idealmente, la estructura más limpia sería una arquitectura en capas con un servidor Wayland raíz, debajo servidores Wayland por usuario, luego un servidor X11 dentro de eso, y encima el administrador de ventanas

• Llevo 15 años usando i3, y cada vez que aparece un proyecto así me pregunto para qué hace falta Wayland
  X11 tendrá defectos, pero se puede hacer casi todo lo que uno quiera
  Wayland siempre parece traer mucha fricción

  • Yo uso Wayland desde la época de KDE 5, y el escalado HiDPI ha sido excelente
    Como usuario de laptop, ha sido una gran ventaja, y el soporte para VRR o HDR también es muchísimo más fácil que en X.org
  • Desde la perspectiva del usuario, simplemente funciona bien
    El ajuste de DPI por pantalla, la prevención del screen tearing y el bloqueo de grabación de pantalla no autorizada por parte de apps vienen resueltos de base
  • Yo me pasé de i3 a sway también por el soporte de DPI
    Ya no tengo que tocar Xorg.conf y eso mejoró mi calidad de vida
    Incluso ahora sigo usando distintos factores de escala según el monitor
  • En X11, configurar altas tasas de refresco siempre fue problemático
  • Un problema reciente que tuve es que Wayland no soporta DeviceEvent
    Necesito una función donde una ventana pueda recibir entrada aunque esté inactiva, y solo el movimiento del mouse funciona como excepción
    Al final lo cambié a Window Event, pero sigue siendo incómodo