lun 16 febrero 2015
Por Javier Cantero
En Linux Graphics Stack .
etiq.: wayland weston
Acaban de salir las nuevas versiones 1.7 de Wayland y
de Weston . Lo interesante de estas versiones no son los
cambios que traen, sino que los desarrolladores han decidido abordar uno
de los mitos que últimamente llevan circulando en los foros cada vez se
habla de Wayland: ¿cuando va a estar terminado? Y la respuesta es: el
protocolo Wayland ya está terminado . El core del protocolo ya no va
a cambiar (es dudoso que a estas alturas se vaya a encontrar un fallo lo
suficientemente importante como para tener que hacer modificaciones en
el diseño), las APIs ya son estables y lo único que queda es
utilizarlas.
Por otro lado, Wayland está construido de tal forma que es muy fácil
añadir extensiones, y de hecho hay una extensión que lleva esperándose
desde hace tiempo: xdg-shell, la extensión que define operaciones de
escritorio de "alto nivel" (como minimizar ventanas). Esta extensión
requiere de la conformidad de los distintos entornos de escritorio (KDE,
GNOME, etc) a los que va dirigida. Pero éstos todavía están trabajando
en sus respectivas implementaciones de Wayland, con lo que la definición
de la extensión no está lo suficientemente madura como para incluirla
oficialmente. Pero es cuestión de tiempo que llegue, y a partir de ahí
el único trabajo en perspectiva para el proyecto será el de
mantenimiento y corrección de errores.
De hecho, es lo que ya ha sucedido en esta versión 1.7, donde los
cambios son fundamentalmente cosméticos: mejorar la documentación,
algunos bugfixes y poco más. Y es lo que seguramente pasará en la ya
planificada versión 1.8 que aparecerá dentro de 3 meses, salvo que
xdg-shell esté lista para entonces.
Otra historia diferente es Weston, el proyecto compañero de Wayland.
Hasta ahora Weston se había descrito como el "compositor de
referencia", pero la idea detrás de este compositor (de este servidor
Wayland para entendernos) era tener un software de pruebas y
experimentación dónde poder evolucionar el protocolo, no la de escribir
un servidor real listo para producción. El problema es que hay una
percepción errónea generalizada que confunde Wayland con Weston, por lo
que los fallos y las carencias de Weston terminan achacándose a Wayland.
O dicho de otra forma, se piensa que Wayland todavía no estaba terminado
porque Weston no funciona todo lo bien que se espera de un software en
producción (cosa que no es).
Es por esto que, ahora que el desarrollo de Wayland se acaba, en el seno
de los desarrolladores del proyecto surgió la cuestión sobre qué hacer
con Weston: "¿Hacia dónde debería ir Weston?" ¿Debería
seguir como hasta ahora, o debería dedicarse a otro propósito? ¿Había
que convertirlo en un auténtico compositor listo para producción? En
palabras de Bryce Harrington (desarrollador y actual
release manager ):
I've noticed over the years, that I can say until I'm blue in the
face that "Wayland is just a protocol, Weston is just a reference
implementation, and you need to look at desktop environments to
provide Wayland compositors;" but people still keep asking me, "Okay,
but when can I ditch X and just use Wayland as my desktop?"
Or the corollary: "If the Wayland protocol was finished some years
ago, and weston is 'just' a reference implementation, why is there
still development effort on it?" The implication being that it's
being called a reference implementation much the way X.org is "just"
a reference implementation of X11.
There is a public [misperception? expectation? belief?] that
Wayland is a software product that will one day arrive and
revolutionize their desktop/smartphone/helicopter/dishwasher
experience. Or at least fix some <mumble> problems that exist with
X's architecture.
So I figure there's two options. One would be to chase this public
sentiment and start handling Weston as a regular desktop server
product development effort. Weston's focus would need to be
restrained, as per the other requirements, so the desktop use case
would be limited to the audience for "minimal/lightweight"
(nvidia-free?) DEs. If this is successful, the law of the slippery
slope will inevitably lead us to implementing more and more features
until it fulfills Zawinski's law.
The other option is to get weston's head and heart aligned, and
strengthen our focus on being "just" a test bed for improving the
Wayland protocol. Give our community's primary attention not to
Weston's users but Wayland's users - Enlightenment, GNOME, KDE, and
other DEs. Survey and study their requirements and look for things
they need across the board. And make it easier for them to bring us
their problems/ideas/needs. Make it convenient for people to do
prototyping and experimentation in Weston first, and then port to
production compositors, rather than vice versa. Instead of unit
testing weston, improve the validation testing of wayland, such that
the same testsuite would run against the weston compositor,
enlightenment compositor, et al to verify that the DEs have properly
implemented the protocol requirements. Instead of delivering a
monolithic Weston package, turn the best bits of it into specialized
libraries that DEs can use too (if they wish). Define a clear process
for 3rd parties to contribute extensions, libraries, and driver
support changes. Finally, work to change public perception to stop
the expectations on producing Weston-the-desktop, by vocally
championing DEs that are already giving solid Wayland-based desktops.
La decisión tomada ha sido (como habéis podido leer en el anuncio de Weston
1.7 ) que no tiene sentido que Weston compita con los
que deben ser los verdaderos compositors Wayland (KWin, GNOME Mutter,
el de Enlightenment E19, el de Hawaii , etc):
We reached concensus that Weston should certainly not aim to become
a end-user usable desktop environment. That rather, Weston's
ultimate goal is to help the Enlightenments, GNOMEs, KDEs, and others
to provide faster, glitch-free desktop environments to users, with a
universal core protocol.
Sin embargo, Weston puede cubrir dos interesantes roles: uno, el de una
biblioteca donde obtener componentes ya hechos y probados de partes
necesarias en cualquier compositor Wayland (como puede ser libinput
para manejar los dispositivos de entrada). El otro, convertirse en un
auténtico banco de pruebas del protocolo que los desarrolladores de
compositors pueden usar para mejorar sus propias implementaciones:
With this comes recognition that we can do more than merely be a test
bed but provide a rich test environment and set of testing tools.
Es evidente (o debería serlo) que una test suite no es el software
adecuado para probar un protocolo, excepto que seas un desarrollador y
lo que busques es verificar el funcionamiento de ciertos detalles del
mismo. Los usuarios que quieran probar un protocolo lo que necesitan es
una implementación robusta, estable y lista para producción, y eso
Weston no lo es. El problema es cómo transmitirlo, cómo hacer llegar al
común de los mortales linuxeros que Weston no es la piedra de toque que
deben usar para evaluar Wayland. A estas alturas va a ser un trabajo
arduo cambiar esa percepción.
Por suerte, las últimas versiones de Mutter, el compositor Wayland de
GNOME, parecen haber alcanzado la calidad requerida para poder evaluar
el potencial de Wayland. Así que ahora al menos sí que hay una opción
real a la que apuntar cuando alguien diga que quiere ver "eso de
Wayland" en acción, mientras esperamos a que vayan llegando el resto de
los compositors y entornos de escritorio prometidos.
:wq