El servidor gráfico ya no importa

Hay un punto de vista sobre el debate Wayland vs Mir que hasta cierto punto contradice el artículo anterior, pero que me gustaría contar porque es igualmente válido (y también por la manía de intentar buscarle tres pies al gato). Ese punto de vista consiste en que, en realidad, tanto Wayland como Mir son relativamente irrelevantes, y no importa quien gane o quien pierda.

Se fundamenta en que la característica principal de estos servidores gráficos de nueva generación es que, en realidad, no hacen prácticamente nada comparado con lo que solían hacer sus antecesores. En los 80 y 90, el servidor X dibujaba los caracteres de las fuentes en la pantalla directamente. En el 2000, el servidor X ofrecía una serie de operaciones de renderizado elementales, y las aplicaciones las utilizaban para dibujar ellas mismas las fuentes. Con Wayland y Mir, el servidor gráfico simplemente ofrece un buffer de memoria, las aplicaciones dibujan en él lo que les de la gana y notifican al servidor cuando terminan. No es muy complicado, por eso es que los toolkits y las aplicaciones han sido portados con relativa facilidad.

Eso por el lado de los clientes. Por el lado de la interacción con las tarjetas gráficas, hemos pasado de un servidor X que ejecutaba drivers 2D, configuraba el modo del monitor, leía el bus PCI directamente e incluso tenía un emulador de BIOS, todo ello en espacio de usuario; a un mundo donde los drivers están en el kernel y se ocupan de todas esas cosas por si mismos. La parte compleja de la aceleración 3D se abstrae en Mesa.

En otras palabras, se han adelgazado considerablemente los servidores gráficos, tanto por el lado de las aplicaciones clientes como por el lado de la interacción con el hardware gráfico. Wayland y Mir son simple pegamento de ambas partes que se ocupa de coordinar el acceso de las aplicaciones a un recurso común (la imagen final que se ve en pantalla). De hecho, una de las cosas más complejas para Wayland y Mir van a ser cosas no directamente relacionadas con gráficos, como la estandarización de la coordinación entre aplicaciones (ej: que la barra de tareas sepa qué ventanas están en un escritorio virtual y cuáles en otro).

La mejor prueba de que los servidores gráficos se han vuelto irrelevantes es que estemos teniendo la discusión Wayland vs Mir: es relativamente sencillo crear un servidor gráfico alternativo, ya que casi todas las piezas del puzzle ya están ahí, sólo hay que unirlas. De hecho, tanto Wayland como Mir no son demasiado grandes. Es decir, no sería un terremoto que alguien apareciera con un tercer servidor gráfico, ya que el coste de oportunidad es mucho menor. Y lo bueno de todo esto es que, como la mayor parte del stack gráfico está fuera del servidor, la mayor parte del trabajo es común y beneficia a ambos servidores.

¿Por qué Canonical avanza tan rápido con Mir? ¿Qué hay de Wayland?

Desde que Canonical anunció que usará Mir por defecto en Ubuntu 13.10, he leído varios comentarios en la tubosféra de gente que se ha sorprendido de que Mir haya avanzado tanto e incluso titulares que hablan de sustitución de X.Org, sin olvidar el qué-hay-de-wayland. La mayoría de personas no conoce gran cosa de cómo funcionan los gráficos en Linux (no les culpo), y los anuncios de Canonical (especialmente los peculiares posts de Mark Shuttleworth) no ayudan demasiado a comprenderlo.

XMir en Ubuntu 13.10

Resumiendo, el servidor gráfico que Canonical va a usar en 13.10 es XMir, lo cual quiere decir que el verdadero servidor gráfico es X.org. Mir se utilizará para dibujar la imagen en la pantalla, funcionando en la práctica como un driver de X.org, que dibujará lo que le piden vía EGL (en el hardware que lo soporte, en el que no lo soporte no se usará XMir). Lo de que el servidor gráfico seguirá siendo en realidad X.org no es menosprecio: será X.org, y no Mir, quien gestione las ventanas, quien comunique a las aplicaciones los eventos de fuentes de entrada, quien las avise de la necesidad de redibujarse, etc.

De ahí que decir que Ubuntu 13.10 usará Mir "en lugar de X" sea una estupidez. X.org no sólo va a estar presente, sino que va a seguir en el centro, e imponiendo sus limitaciones habituales.

Dada la arquitectura e historial de X.org, es fácil prever que haya benchmarks en los que XMir sea más rápido que los drivers "2D" de X.org, pero también otros donde no lo sea (porque para las operaciones "2D" que usan los toolkits de escritorio tradicionales, la aceleración "3D" vía Mesa a veces es más lenta que la aceleración "2D" del driver, o que hacerlo en la CPU). Hace años que existen intentos similares de utilizar aceleración GL en X.org: Xgl, glucose, o más recientemente Glamor. En Phoronix (y si, ya se que sus benchmarks no son los mejores del mundo) han concluído que XMir es más lento que X.org. Y el programador de kwin ya ha avisado de que Xmir causa pequeños defectos en kwin en ocasiones.

Una de cal y otra de arena, pero a Canonical no le preocupa demasiado porque quiere avanzar rápido con Mir para la siguiente versión, 14.04, que es LTS. Me temo que los usuarios de 13.10 van a hacer un poco de conejillos de indias, aunque lo más probable es que la mayoría no tenga problemas o no note diferencias de velocidad ni en un sentido ni en otro, más allá del placebo.

Wayland

Respecto a Wayland, hay gente que a la luz de esta noticia se congratula que Ubuntu se libre tan rápido de X.org (falso, como ya hemos visto), y se queja de que, a pesar de todo este tiempo de ventaja, Wayland sigue sin ver la luz y de que se esté desarrollando a velocidad glacial. Afirmar tal cosa es no comprender lo que es Wayland, lo que pretende, y la diferencia que lo separa de Mir.

Wayland hace tiempo que está "preparado". Por ejemplo, el equivalente a XMir que Ubuntu usará en 13.10, XWayland, existe hace tiempo y se puede usar. Respecto al reemplazo completo de X.org, si esperan a que Wayland "progrese" y pueda usarse como servidor gráfico, pueden esperar sentados, porque eso no va a ocurrir. Ni tan siquiera Weston, que es el servidor gráfico de ejemplo de Wayland, va a mejorar en el sentido de llegar a ser usado como reemplazo de X.org, ya que, como digo, es tan sólo de ejemplo. No veremos jamás una versión de Wayland/Weston que las distros adopten como reemplazo de X.org, sino una versión de GNOME o KDE en la que sus gestores de ventanas empiecen a utilizar Wayland. La próxima versión de GNOME ya añade soporte de Wayland en gnome-shell, kwin también está en ello.

Y ahí, diminuta pero presente e importante, está la diferencia fundamental con Mir. Como aspirante a reemplazar X.org, Wayland es algo más que la creación de un servidor gráfico alternativo. En realidad, es un meta-proyecto colaborativo que involucra a toda la comunidad gráfica libre para coordinarse y establecer estándares y mejorar el protocolo a la vez que se porta software a la API de Wayland. Aunque XWayland exista y esté soportado, no es el centro de atención; para un proyecto que aspira a reemplazar X.org, limitarse a XWayland no es atractivo, su objetivo es proporcionar un escritorio Wayland puro. Y esta exaltación comunitaria no es un capricho, el mundo gráfico es muy extenso y complejo y para hacer las cosas bien es imprescindible escuchar a todos (personalmente creo que el mayor fallo de Mir es el hecho de ser una solución autista, diseñada por y para satisfacer los caprichos de un solo software, Unity).

La manera correcta de medir el progreso de Wayland, por tanto, no es la evolución de Wayland, que por mucho que evolucione no va a sustituir a X.org por si mismo, sino 1) la aparición de servidores gráficos / gestores de ventana que implementen la API de Wayland (y hay unos cuantos en camino, incluyendo algunos muy psicodélicos) 2) la migración a APIs Wayland de aplicaciones con "propósito gráfico especial" (que no se porten automáticamente con el port de un toolkit: ej, reproductores de vídeo).

Desde esta perspectiva las cosas son bastante diferentes. GTK y QT tienen soporte de Wayland, y de Mir también gracias a parches de Canonical, y bien es cierto que con eso se soportan casi todas las aplicaciones. Pero Wayland, además también está soportado en Clutter, en EFL (Enlightenment), en SDL, en mplayer, en XBMC, en Chromium, en WebkitGTK, en bindings para Java. En la próxima versión, Wayland incluirá en el protocolo soporte de gestión de color, soporte de sub-superficies (útil para implementar plugins dentro del navegador como dios manda,), pantallas de alta resolución, soporte de "multi-asiento". Algunas de esas cosas son mejoras del protocolo, otras características de Weston, algunas son ambas cosas. Pero todas ellas están a un nivel completamente diferente de XMir, o XWayland: se trata de reemplazar a X.org todo lo que se pueda, no de satisfacer una visión particular con un entorno de escritorio.

Concurso de aplicaciones para Tizen

El otro decía que Tizen es una de las pruebas de que los fabricantes quieren intentar fabricarse alternativas a Android a largo plazo, de no ser así nadie se gastaría un sólo dólar en mantenerlo vivo. Como complemento, hoy se ha sabido que la Linux Foundation ha anunciado el concurso Tizen App Challenge con el que premiarán a las mejores aplicaciones. Total de fondos del concurso: 4 milloncejos de nada. Además, parece que están moviéndose por conferencias e incluso escribiendo libros. Si uno echa un ojo a la documentación parece que el proyecto ha montado incluso un entorno nativo propio bastante completo, que curiosamente se parece mucho al de Bada, incluso el navegador web de la documentación es el mismo. Lo dicho, mucho dinero.