Software Libre para Guanajuato

Bienvenido(a) a Grupo Linuxero de Bajío
domingo, septiembre 24 2017 @ 08:45 CEST

Wayland

Artículos

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  |
+----------+
  • El kernel recibe un evento desde un dispositivo de entra y se lo envía a X.
  • El servidor X determina a qué ventana afecta dicho evento y se lo envía al cliente que ha sido seleccionado. No obstante, el servidor X no sabe cómo hacerlo correctamente, ya que la posición de las ventanas están controlados por el compositor.
  • El cliente X examina el evento que le envió el servidor y decide qué hacer. Luego el cliente envía una petición de renderización de vuelta al servidor.
  • Cuando el servidor X recibe la petición de renderización, se la envía al driver del hardware encargado de la renderización. Luego calcula la región que ha cambiado y le envía al compositor un evento tipo damage.
  • El evento tipo damage le dice al compositor que algo ha cambiado en la ventana y que debe de recomponer esa parte de la pantalla donde la ventana es visible. Y aunque el compositor conoce la composición de toda la escena, depende del servidor X para renderizar.
  • El servidor X recibe la petición de renderización del compositor, copia el búfer del compositor y finalmente pinta la escena en la pantalla.

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  |
   +----------+
  • El kernel recibe un evento y lo envía al compositor, igual que antes.
  • El compositor recorre el grafo que representa la escena (scenegraph) y determina correctamente a qué cliente corresponde dicho evento.
  • Igual que en el caso de X, el cliente recibe el evento, actualiza su estado y, a diferencia de X, el cliente mismo realiza su propia renderización, luego solicita al compositor actualizar la escena.
  • El compositor recolecta las solicitudes damage de los clientes y recompone la escena. Finalmente, el compositor mismo pide al kernel pintar el búfer final, sin copias extras.

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.

Opciones de la Noticia

Wayland | 0 comentarios | Crea una cuenta nueva
Los siguientes comentarios son de la persona que los haya enviado. Este sitio no se hace responsable de las opiniones expresadas por los participantes en los foros y secciones de comentarios, y el hecho de publicar las mismas no significa que esté de acuerdo con ellas.