Grupo Linuxero del Bajío

Wayland

Víctor Manuel Jáquez Leal

Parafraseando un famoso manifiesto:

Un fantasma recorre el software libre: el fantasma de Wayland. Todas las fuerzas del viejo X Window System se han unido para reemplazar a este pesado protocolo con uno más compacto y moderno.

El problema de X Window es que se desarrolló cuando aún no había tarjetas de vídeo con aceleración gráfica que pudieran hacer composición de vídeo, tales como transparencias (composición alfa), desvanecidos, sombreados, escalado, rotación, etcétera. Todo esto en tiempo real.

En la década de los ochentas, cuando surgió X Window, el problema se limitaba a pintar cuadrados en una pantalla. Sin embargo, ahora queremos cosas más complejas. La solución a estas nuevas demandas ha sido a base de extensiones a X Window, que lo han convertido en una pesadilla.

De manera general, actualmente X Window tiene esta arquitectura:

+----------+
| X Client |
+----------+
      |
+----------+   +------------+
| X Server |---| Compositor |
+----------+   +------------+
      |
+----------+
|  Kernel  |
+----------+

Como se puede apreciar, hay varios problemas con esta arquitectura: cambios de contexto innecesarios, copia de búferes, complejidad innecesaria, pasos innecesarios, etcétera, que hacen a X Window una muy mala opción para sistemas embebidos.

Mucha de esta complejidad extra es debido a la capacidad de X Window de transmitir, de manera transparente, información gráfica a través de la red. Es decir, podemos tener un servidor X remoto, y clientes X locales, en terminales tontas. Sin embargo, aunque debatible, esta característica tiene poco uso en comparación con la complejidad que impone.

En 2008, Kristian Høgsberg, se preguntaba cómo simplificar la pesadilla de X Window y comenzó a diseñar un reemplazo: Wayland.

Comenzó por tirar a la basura el servidor X junto con los manejadores de ventanas (window managers). El kernel y los compositores habían tomado muchas de las responsabilidades originales del servidor X y del manejadores de ventanas; además, lo hacían de manera más eficiente y mejor:

+----------------+
| Wayland Client |
+----------------+
        |
+--------------------+
| Wayland Compositor |
+--------------------+
        |
   +----------+
   |  Kernel  |
   +----------+

La pregunta es obvia ¿si quitamos el servidor X, cómo, los clientes, realizarían su propia renderización?

¡Sorpresa! Esto ya se hace en X Window con DRI2, que literamente significa Infraestructura de Renderización Directa: el cliente y el servidor comparten un mismo búfer de memoria de vídeo. El cliente puede entonces utilizar una biblioteca como OpenGL o Cairo para renderizar directamente sobre el búfer. El compositor, entonces, puede tomar dicho búfer y usarlo como una textura cuando compone la escena final.

Pero volvamos atrás por un momento: ¿qué demonios es Wayland? ¿Otro X Window? Sí y no. Formalmente Wayland es un protocolo de comunicación asíncrono entre un compositor y sus clientes. Este protocolo sirve para que los clientes obtengan un búfer, hagan su renderización sobre él y se lo entreguen al compositor para componga la escena y finalmente la presente en pantalla. A bajo nivel, este protocolo es un clásico IPC (comunicación entre procesos) usando sockets Unix y está escrito directamente en C; a alto nivel, es una interfaz de programación descrita en XML que se convierte automáticamente en una API en C.

Por otro lado, el proyecto Wayland tiene una implementación de compositor, usado como referencia para otros proyectos, llamado Weston. El proyecto GNOME, por ejemplo, tiene su propia implementación de compositor dentro de Mutter, que en X, es el manejador de ventanas oficial del proyecto.

Los puristas seguramente pondrán el grito en el cielo y defenderán X Window, tal como otros defienden el init de System V contra la amenaza de systemd. No obstante tenemos palabras de aliento para ellos: X siempre será relevante, tal como los compiladores de Fortran lo siguen siendo.