Wayland y Qt
Wayland se desarrolló como alternativa a X11 en Linux. Su principal objetivo es gestionar cómo se muestra el contenido de las aplicaciones juntas en una pantalla compartida, y cómo un usuario puede interactuar con múltiples aplicaciones que comparten los mismos dispositivos de entrada.
Esta función en un sistema operativo suele denominarse servidor de pantalla. El servidor de pantalla Wayland también puede ser llamado a veces un compositor y un gestor de ventanas, en referencia a las tareas específicas que realiza como parte de su deber.
A continuación, daremos una breve introducción a Wayland y su papel en Qt. Para más detalles y antecedentes sobre el propio Wayland, consulta la documentación oficial.
Qué es un Servidor de Visualización
El servidor de pantalla es la parte del sistema operativo que gestiona la pantalla y otros recursos compartidos. En un sistema de escritorio típico, puedes tener muchas aplicaciones independientes ejecutándose al mismo tiempo, cada una esperando poder renderizar gráficos en la pantalla y recibir entradas.
El servidor de visualización es un enlace entre la aplicación y los recursos compartidos, como la pantalla y los dispositivos de entrada. Un servidor de visualización típico en un sistema de escritorio colocará el contenido de la aplicación en distintas "ventanas" rectangulares, que el usuario puede mover y cambiar de tamaño. El servidor de visualización se asegura de que el contenido de la aplicación se muestre en la posición correcta en la pantalla, de que la ventana activa reciba las entradas del teclado, de que las ventanas superpuestas se dibujen en el orden correcto, etc.
En otros tipos de sistemas, el servidor de pantalla puede ser más restrictivo. Si la pantalla es el panel de instrumentos de un coche, o el panel de control de una carretilla elevadora, por ejemplo, puede que no sea deseable mover y cambiar el tamaño de las ventanas. En su lugar, cada aplicación puede estar bloqueada en un área predefinida de la pantalla y recibir entradas de dispositivos preasignados.
En cualquier caso, mientras haya varios procesos aislados compitiendo por los mismos recursos, un servidor de pantalla es útil.
El papel de Wayland
El nombre Wayland puede referirse a varios elementos relacionados:
- Un conjunto de protocolos para la comunicación entre un servidor de visualización y sus clientes.
- Una biblioteca escrita en C con funciones para la comunicación entre procesos, que sirve de base para implementar dichos protocolos.
- Un lenguaje basado en XML para ampliar el protocolo, así como una herramienta para generar código vinculante en C a partir de dichas ampliaciones.
Qt proporciona implementaciones tanto para el lado cliente como para el lado servidor del protocolo.
Las aplicaciones Qt normales pueden ejecutarse como clientes en un servidor de visualización Wayland seleccionando el plugin QPA "wayland" (es el predeterminado en ciertos sistemas). Puede hacerlo utilizando la opción -qpa wayland. Además, el módulo Qt Wayland Compositor para desarrollar el propio servidor de visualización.
Qt también dispone de una práctica funcionalidad para ampliar fácilmente los protocolos Wayland con nuevas interfaces.
Wayland y otras tecnologías
En el escritorio de Linux, Wayland es una alternativa a X11 y las extensiones relacionadas. Se trata de un servidor de visualización de composición en su núcleo, y el término "compositor" se utiliza a menudo para describir el servidor Wayland. Esto significa que los clientes renderizarán el contenido en un búfer fuera de la pantalla, que más tarde se "compondrá" con otros clientes en la pantalla, permitiendo efectos de ventana como sombras, transparencia, desenfoque del fondo, etc.
Un principio de diseño importante de los protocolos X11 originales es que el servidor de visualización puede ejecutarse en un terminal delgado con sólo una pantalla y dispositivos de entrada. Sus clientes se ejecutarían en sistemas remotos con mayor capacidad de procesamiento, comunicándose con el servidor a través de una conexión de red.
En cambio, Wayland se ha diseñado teniendo en cuenta que, en las configuraciones modernas, el cliente y el servidor de visualización suelen ejecutarse en el mismo hardware. La informática distribuida, el almacenamiento remoto y la funcionalidad de escritorio remoto suelen gestionarse a través de otros mecanismos. El diseño de este protocolo permite compartir la memoria gráfica entre el cliente y el servidor: Cuando el compositor coloca el contenido del cliente en la pantalla, puede simplemente copiarlo de una parte de la memoria gráfica a otra.
Para que esto funcione de forma óptima, el controlador de gráficos debe ser compatible con Wayland. Este soporte se proporciona a través de una extensión de EGL que se llama EXT_platform_wayland.
Nota: Qt Wayland también soporta composición en sistemas donde EXT_platform_wayland no está soportado, ya sea a través de XComposite o copiando el contenido de la aplicación a la memoria compartida de la CPU. Pero para un rendimiento óptimo, recomendamos sistemas con soporte de controladores.
X11 se ha ampliado para soportar funciones como la composición y el renderizado directo, pero Wayland se ha diseñado desde cero en torno a este caso de uso. También pretende ser pequeño y extensible, en contraste con la complejidad que se ha desarrollado en X11 con el tiempo.
Extensibilidad y sistemas integrados
Dado que Wayland tiene un núcleo mínimo y es fácilmente extensible, es una herramienta ideal para construir plataformas Linux integradas.
Las funciones del sistema de ventanas de escritorio, por ejemplo, no forman parte del núcleo del protocolo. En su lugar, Wayland cuenta con una categoría especial de extensiones de protocolo llamadas "shells" que proporcionan al cliente una forma de gestionar sus superficies. Las funciones de escritorio se proporcionan a través de un intérprete de comandos llamado XDG Shell. Para otros tipos de sistemas, se puede utilizar un "shell" más especializado (y quizás más restrictivo). Por ejemplo, al crear sistemas In-Vehicle Infotainment, puede ser preferible utilizar IVI Shell.
El servidor Wayland emite una lista de sus protocolos soportados (o "interfaces") cuando un cliente se conecta, y el cliente puede enlazarse a los que quiera usar. Puede tratarse de cualquiera de las interfaces estándar, pero también es fácil añadir nuevas extensiones. Wayland define un formato XML fácilmente comprensible para definir protocolos y la herramienta waylandscanner puede utilizarse para generar código C a partir de ellos. (En Qt, también tenemos qtwaylandscanner que genera código C++ de vinculación adicional).
Cuando un cliente se vincula a una interfaz, puede hacer "peticiones" al servidor y éste puede enviar "eventos" al cliente. Las peticiones y los eventos, así como sus argumentos, se definen en el archivo XML que describe el protocolo.
Para construir una plataforma desde cero, cuando se controla el código tanto del servidor como de los clientes, añadir extensiones es una forma fácil y controlada de añadir características al sistema operativo.
Multiproceso o monoproceso
Cuando se construye una plataforma embebida sencilla con Qt, una opción perfectamente viable es tener todas las partes de la interfaz de usuario ejecutándose en un único proceso. Sin embargo, a medida que el sistema se vuelve más complejo, es posible que desee considerar un sistema multiproceso en su lugar. Aquí es donde entra Wayland. Con Qt, en cualquier punto de tu proceso de desarrollo, puedes elegir cambiar entre proceso único y multiproceso.
Ventajas del multiproceso
Los siguientes diagramas ilustran la diferencia entre los sistemas multiproceso y monoproceso.
Arquitectura cliente multiproceso
Arquitectura cliente monoproceso
El módulo Qt Wayland Compositor es ideal para crear el servidor de visualización y el compositor en sistemas multiproceso en Linux embebido. El uso de multiproceso tiene las siguientes ventajas:
| Estabilidad | |
|---|---|
| Más fácil de recuperar cuando los clientes se cuelgan o se bloquean | Si tienes una interfaz de usuario compleja, el multiproceso es útil porque si una parte de la interfaz se bloquea, no afecta a todo el sistema. Del mismo modo, la pantalla no se congelará, incluso cuando un cliente se bloquee. Nota: Si su cliente está obligado por ley a mostrar información crítica para la seguridad, considere el uso de Qt Safe Renderer Overview. |
| Protección contra posibles fugas de memoria | En un sistema multiproceso, si un cliente tiene una fuga de memoria y consume mucha memoria, esa memoria se recupera cuando ese cliente sale. En cambio, en un sistema monoproceso, la fuga de memoria permanece hasta que se reinicia todo el sistema. |
| Seguridad |
|---|
| En un sistema monoproceso, todos los clientes pueden acceder a la memoria de los demás. Por ejemplo, no hay aislamiento para la transferencia de datos sensibles; cada línea de código debe ser igualmente fiable. Este aislamiento existe, por diseño, en los sistemas multiproceso. |
| Rendimiento |
|---|
| Si tienes una CPU con varios núcleos, un sistema multiproceso puede ayudarte a distribuir la carga uniformemente entre los diferentes núcleos, haciendo un uso más eficiente de tu CPU. |
| Interoperabilidad |
|---|
| Puedes interactuar con clientes que no sean Qt en un sistema multiproceso, siempre que tus clientes entiendan Wayland o X11. Por ejemplo, si utiliza gstreamer para vídeo o si desea utilizar una aplicación de navegación construida con otro conjunto de herramientas de interfaz de usuario, puede ejecutar estos clientes junto con sus otros clientes basados en Qt. |
Ventajas y desventajas del multiproceso
Al pasar de un único proceso a multiproceso, es importante ser consciente de las siguientes ventajas y desventajas:
- Mayor consumo de memoria de vídeo
- Mayor consumo de memoria principal
- Almacenamiento repetido de recursos gráficos
- Latencia de entrada
| Mayor consumo de memoria de vídeo |
|---|
| Esto puede suponer una limitación para los dispositivos integrados. En multiproceso, cada cliente necesita tener su propio búfer gráfico, que envía al compositor. En consecuencia, se utiliza más memoria de vídeo en comparación con el caso de un solo proceso: donde todo se dibuja a la vez y no hay necesidad de almacenar las diferentes partes en búferes intermedios. |
| Mayor consumo de memoria principal |
|---|
| Aparte de algunos gastos adicionales a nivel del sistema operativo, la ejecución de varios clientes también puede consumir más memoria principal, ya que algunas partes deben duplicarse una vez por cliente. Por ejemplo, si ejecutas QML, cada cliente necesita un motor QML distinto. Por consiguiente, si ejecutas un único cliente que utiliza Qt Quick Controls, se carga una vez. Si luego divides este cliente en varios clientes, estás cargando Qt Quick Controls varias veces, lo que se traduce en un mayor coste de arranque para inicializar tus clientes. |
| Almacenamiento repetido de recursos gráficos |
|---|
| En un sistema de proceso único, si utilizas las mismas texturas, fondos o iconos en muchos sitios, esas imágenes sólo se almacenan una vez. En cambio, si utilizas estas imágenes en un sistema multiproceso, tendrás que almacenarlas varias veces. En este caso, una solución es compartir recursos gráficos entre clientes. Qt ya permite compartir recursos de imagen en memoria principal entre procesos sin involucrar a Wayland. En cambio, compartir texturas de la GPU entre procesos requiere soluciones más complejas. Con Qt, estas soluciones pueden desarrollarse como protocolos de extensión de Wayland y con QQuickImageProvider, por ejemplo. |
| Latencia de entrada a fotón |
|---|
| En un sistema de un solo proceso, la aplicación accede directamente a la memoria intermedia del fotograma principal. Esto significa que la latencia entre los eventos de entrada y su reflejo en pantalla puede minimizarse en una configuración de este tipo. En un sistema multiproceso, el contenido de la aplicación tiene que ser almacenado en triple buffer para asegurar que el cliente no está dibujando en los buffers mientras están siendo leídos simultáneamente por el servidor, ya que esto causaría tearing. Esto significa que hay una latencia implícita en un sistema multiproceso. |
Por qué usar Wayland en lugar de X11 o soluciones personalizadas
Como se ha descrito anteriormente, X11 no es una solución óptima para las configuraciones típicas de los sistemas actuales. Es bastante grande y complejo, y carece de capacidad de personalización. De hecho, es difícil ejecutar un cliente de forma fluida con X11, y alcanzar los 60 fps sin tearing. Wayland, por el contrario, es más fácil de implementar, tiene mejor rendimiento, y contiene todas las partes necesarias para funcionar eficientemente en hardware gráfico moderno. Para sistemas embebidos y multiproceso en Linux, Wayland es el estándar.
Sin embargo, si trabajas con hardware antiguo o aplicaciones heredadas, Wayland puede no ser una buena opción. El protocolo Wayland está diseñado pensando en la seguridad y el aislamiento, y es estricto/conservador sobre qué información y funcionalidad está disponible para los clientes. Aunque esto conduce a una interfaz más limpia y segura, algunas funcionalidades que las aplicaciones heredadas esperan pueden no estar disponibles en Wayland.
En particular, hay tres casos de uso comunes en los que Wayland puede no ser la mejor opción:
- El hardware o plataforma es antiguo y sólo soporta X11; en cuyo caso no tienes elección.
- Tienes que soportar aplicaciones heredadas que dependen de características que están ausentes en el protocolo Wayland por seguridad y simplicidad.
- Tienes que soportar aplicaciones heredadas que utilizan un kit de herramientas de interfaz de usuario que no se ejecuta en Wayland en absoluto. En algunos casos, es posible solucionar este problema ejecutando esas aplicaciones en XWayland.
Cuando X11 era muy popular, los desarrolladores escribían sus propias soluciones personalizadas para evitar los problemas de X11. Las versiones antiguas de Qt tenían el Qt Windowing System (QWS), que ahora está descontinuado. Hoy en día, la mayoría de estos casos de uso están cubiertos por Wayland, y las soluciones personalizadas son cada vez menos comunes.
Qué ofrece Qt Wayland
Para clientes
Los clientes Qt pueden ejecutarse en cualquier compositor Wayland, incluido Weston, el compositor de referencia desarrollado como parte del proyecto Wayland.
Cualquier programa Qt puede ejecutarse como cliente Wayland (como parte de un sistema multiproceso) o como cliente independiente (proceso único). Esto se determina en el arranque, donde puedes elegir entre los diferentes backends. Durante el proceso de desarrollo, puedes desarrollar primero el cliente en el escritorio y probarlo después en el hardware de destino. No es necesario ejecutar los clientes en el hardware de destino todo el tiempo.
Desarrollo de clientes monoproceso
Si desarrolla en una máquina Linux, también puede ejecutar el compositor dentro de una ventana en su máquina de desarrollo. Esto le permite ejecutar clientes en un entorno que se asemeja mucho al dispositivo de destino. Sin reconstruir el cliente, también puede ejecutarlo con -platform wayland para ejecutarlo dentro del compositor. Si utiliza -platform xcb (para X11), puede ejecutar el cliente en el escritorio. En otras palabras, puede empezar a desarrollar sus clientes antes de que el compositor esté listo para su uso.
Para servidores
El servidor, o compositor, se conecta a la pantalla y muestra el contenido de cada cliente en la pantalla. El compositor gestiona la entrada y envía los eventos de entrada al cliente correspondiente. A su vez, cada cliente se conecta al compositor y envía el contenido de sus ventanas. El compositor decide:
- Cómo y dónde mostrar el contenido
- Qué contenido mostrar
- Qué hacer con los distintos buffers gráficos de los clientes
Esto significa que depende del compositor decidir qué es un sistema multiproceso. Por ejemplo, los clientes podrían formar parte de una escena 3D con ventanas en las paredes, en un sistema VR, mapeados en una esfera, etc.
El sitio Qt Wayland Compositor es una API para construir tu propio compositor. Te da total libertad para construir una interfaz de usuario de compositor personalizada y gestionar las ventanas de varios clientes. Puedes combinar tanto Qt Quick como QML con Qt Wayland Compositor para crear interfaces de usuario impresionantes e imaginativas. Para más información, consulte Qt Wayland Compositor.
Qt también proporciona API potentes y fáciles de usar para implementar extensiones Wayland y utilizarlas desde QML o C++.
Contenido relacionado
© 2026 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.
