Wayland

Wayland es un protocolo de servidor de pantalla. Está destinado a convertirse en el sucesor del sistema X Window. Puedes encontrar una comparación entre Wayland y Xorg en Wikipedia.

Los servidores de pantalla que utilizan el protocolo Wayland se llaman compositores porque también actúan como gestores de ventanas de composición. A continuación puede encontrar una lista de compositores de Wayland.

Para la compatibilidad hacia atrás para ejecutar sin problemas aplicaciones X11 heredadas, se puede utilizar XWayland, que proporciona un servidor X en Wayland.

Requerimientos

La mayoría de los compositores de Wayland sólo funcionan en sistemas que utilizan la configuración del modo Kernel. Wayland por sí mismo no proporciona un entorno gráfico; para ello se necesita también un compositor (ver la siguiente sección), o un entorno de escritorio que incluya un compositor (por ejemplo, GNOME o KDE).

Para que el controlador de la GPU y el compositor de Wayland sean compatibles deben soportar la misma API de búfer. Hay dos APIs principales: GBM y EGLStreams.

Apoyo a la API del buffer Soporte del controlador de la GPU Soporte del compositor de Wayland
GBM Todos excepto NVIDIA Todos
EGLStreams NVIDIA GNOME, KDE, Weston (con un parche de terceros)

Compositores

Ver Window manager#Types para la diferencia entre Tiling y Stacking.

Tiling

  • Cagebreak – Basado en cage, inspirado en ratpoison.

https://github.com/project-repo/cagebreak || cagebreakAUR cagebreak-binAUR

  • Cardboard – Compositor de desplazamiento, inspirado en PaperWM, basado en wlroots.

https://gitlab.com/cardboardwm/cardboard || no empaquetado? buscar en AUR

  • dwl – Compositor Wayland similar a dwm basado en wlroots.

https://github.com/djpohly/dwl || dwlAUR

  • japokwm – Compositor dinámico de Wayland basado en la creación de diseños, basado en wlroots.

https://github.com/werererer/japokwm | ¿no empaquetado? buscar en AUR

  • river – Compositor dinámico de Wayland basado en dwm y bspwm.

https://github.com/ifreund/river || river-gitAUR

  • Sway – Compositor de Wayland compatible con i3 y basado en wlroots.

https://github.com/swaywm/sway || sway

  • Velox – Simple gestor de ventanas basado en swc, inspirado en dwm y xmonad.

https://github.com/michaelforney/velox || veloxAUR

  • waymonad – Compositor de Wayland inspirado en xmonad escrito en Haskell.

https://github.com/waymonad/waymonad |¿No está empaquetado? busque en AUR

Stacking

  • Enlightenment – Vea Enlightenment#Manually. Más información:

https://www.enlightenment.org/ || enlightenment

  • Greenfield – Se ejecuta en un navegador web y puede mostrar aplicaciones remotas.

https://greenfield.app/ || no empaquetado? buscar en AUR

  • Grefsen – Compositor Qt/Wayland que proporciona un entorno de escritorio mínimo.

https://github.com/ec1oud/grefsen |¿No está empaquetado? buscar en AUR

  • hikari – Compositor basado en wlroots inspirado en cwm que se desarrolla activamente en FreeBSD pero también soporta Linux.

https://hikari.acmelabs.space/ | hikariAUR

  • KDE KWin – Ver KDE#Starting Plasma.

https://userbase.kde.org/KWin || kwin

  • Liri Shell – Parte de Liri, construido usando QtQuick y QtCompositor como compositor para Wayland.

https://github.com/lirios/shell || liri-shell-gitAUR

  • labwc – Compositor basado en wlroots inspirado en Openbox.

https://github.com/johanmalm/labwc || labwc-gitAUR

  • Mutter – Vea GNOME#Starting.

https://gitlab.gnome.org/GNOME/mutter || mutter

  • wayfire – Compositor 3D inspirado en Compiz y basado en wlroots.

https://wayfire.org/ || wayfireAUR

  • Weston – implementación de referencia de un compositor Wayland.

https://gitlab.freedesktop.org/wayland/weston || weston

  • wio – compositor basado en wlroots que pretende replicar el aspecto y la sensación del escritorio Rio de Plan 9.

https://wio-project.org/ | ¿no está empaquetado? search in AUR

Other

  • Cage – Muestra una única aplicación a pantalla completa como un quiosco.

https://www.hjdskes.nl/projects/cage/ || cage

  • Maze Compositor – Renderiza ventanas en un laberinto 3D usando Qt.

https://github.com/imbavirus/mazecompositor || not packaged? search in AUR

  • Motorcar – Compositor de Wayland para explorar ventanas 3D usando realidad virtual.

https://github.com/evil0sheep/motorcar || no empaquetado? search in AUR

Algunos de los anteriores pueden soportar gestores de pantalla. Compruebe /usr/share/wayland-sessions/compositor.desktop para ver cómo se inician.

Administradores de pantalla

Los administradores de pantalla enumerados a continuación admiten el lanzamiento de los compositores de Wayland. La columna «Tipo» indica si el gestor de pantalla soporta ejecutarse en Wayland o no.

Nombre Tipo Descripción
GDM Se ejecuta en Wayland Gestor de pantalla de GNOME.
Greetd Demonio de inicio de sesión Demonio de inicio de sesión mínimo y flexible.
LightDM Se ejecuta en X11 Gestor de pantalla en varios escritorios.
Ly Ejecuta en consola Gestor de pantallaTUI escrito en C
SDDM Ejecuta en X11 Gestor de pantalla basado en QML.
tbsm Se ejecuta en consola Simple lanzador de sesiones CLI escrito en bash puro.

Librerías de interfaz de usuario

Vea los detalles en el sitio web oficial.

GTK

Los paquetes gtk3 y gtk4 tienen el backend Wayland habilitado. GTK se ajustará por defecto al backend de Wayland, pero es posible anularlo a Xwayland modificando una variable de entorno: GDK_BACKEND=x11.

Qt

Para habilitar el soporte de Wayland en Qt 5 o 6, instale el paquete qt5-wayland o qt6-wayland, respectivamente.

Para ejecutar una aplicación Qt con el plugin Wayland , utilice la variable de entorno -platform wayland o QT_QPA_PLATFORM=wayland. Para forzar el uso de X11 en una sesión de Wayland, utilice QT_QPA_PLATFORM=xcb. Esto puede ser necesario para algunas aplicaciones propietarias que no utilizan la implementación de Qt del sistema, como zoomAUR.

En algunos compositores, por ejemplo sway, las aplicaciones Qt que se ejecutan de forma nativa pueden tener funcionalidad perdida. Por ejemplo, KeepassXC será incapaz de minimizar a la bandeja. Esto puede solucionarse instalando qt5ct y configurando QT_QPA_PLATFORMTHEME=qt5ct antes de ejecutar la aplicación.

Clutter

El kit de herramientas Clutter tiene un backend de Wayland que le permite ejecutarse como cliente de Wayland. El backend está habilitado en el paquete Clutter.

Para ejecutar una aplicación Clutter en Wayland, establezca CLUTTER_BACKEND=wayland.

SDL2

Para ejecutar una aplicación SDL2 en Wayland, establezca SDL_VIDEODRIVER=wayland.

Nota: Muchos juegos propietarios vienen empaquetados con versiones antiguas de SDL, que no soportan Wayland y podrían romperse por completo si establece SDL_VIDEODRIVER=wayland. Para forzar que la aplicación se ejecute con XWayland, establezca SDL_VIDEODRIVER=x11.

GLFW

Para usar GLFW con el backend de Wayland, instale el paquete glfw-wayland (en lugar de glfw-x11).

GLEW

El paquete glew-waylandAUR actualmente todavía no funciona con muchas aplicaciones basadas en GLEW, así que la única opción es usar glew con Xwayland. Ver FS#62713.

EFL

EFL tiene soporte completo para Wayland. Para ejecutar una aplicación EFL en Wayland, vea la página del proyecto Wayland.

winit

Winit es una biblioteca de manejo de ventanas en Rust. Por defecto se utilizará el backend de Wayland, pero es posible anularlo a Xwayland modificando una variable de entorno: WINIT_UNIX_BACKEND=x11.

XWayland

XWayland es un servidor X que se ejecuta bajo Wayland. Proporciona compatibilidad hacia atrás para las aplicaciones X11 heredadas.

Para utilizarlo, instale el paquete xorg-xwayland.

XWayland se inicia a través de un compositor, por lo que debe comprobar la compatibilidad con XWayland y las instrucciones sobre cómo iniciar XWayland, con el compositor de su elección.

Nota:

  • Respecto a la seguridad: XWayland es un servidor X, por lo que no tiene las características de seguridad de Wayland.
  • Por ahora el controlador propietario de Nvidia no soporta la aceleración de la GPU para XWayland. Ver este o este pull request para el estado del soporte de XWayland.

Solución de problemas

Corrección de color

Ver Backlight#Color correction.

Movimiento lento, fallos gráficos y cuelgues

Los usuarios de gnome-shell pueden experimentar problemas de visualización cuando cambian a Wayland desde X. Una de las causas puede ser el CLUTTER_PAINT=disable-clipped-redraws:disable-culling configurado por usted mismo para gnome-shell basado en Xorg. Sólo trate de eliminarlo de /etc/environment u otros archivos rc para ver si todo vuelve a la normalidad.

No se puede abrir la pantalla: :0 con aplicaciones basadas en Electron

Asegúrese de que no ha establecido GDK_BACKEND=wayland. Establecerlo globalmente romperá las aplicaciones Electron.

Visualización remota

  • (20200206) wlroots (usado por sway) ofrece un backend VNC vía wayvncAUR desde la versión 0.10. El backend RDP ha sido eliminado. .
  • (20180401) mutter tiene ahora el escritorio remoto habilitado en tiempo de compilación, ver y gnome-remote-desktop para más detalles.
  • Hubo una fusión de FreeRDP en Weston en 2013, habilitado a través de una bandera de compilación. El paquete weston lo tiene habilitado desde la versión 6.0.0.
  • waypipe-gitAUR es un proxy transparente para aplicaciones Wayland, con un comando wrapper para ejecutar sobre SSH

Input grabbing en juegos, escritorio remoto y ventanas VM

En contraste con Xorg, Wayland no permite el agarre exclusivo de dispositivos de entrada, también conocido como agarre activo o explícito (e.g. teclado, ratón), en su lugar, depende del compositor de Wayland para pasar los atajos de teclado y confinar el dispositivo de puntero a la ventana de la aplicación.

Este cambio en el agarre de la entrada rompe el comportamiento de las aplicaciones actuales, lo que significa:

  • Las combinaciones de teclas y los modificadores serán capturados por el compositor y no serán enviados al escritorio remoto y a las ventanas de la máquina virtual.
  • El puntero del ratón no se limitará a la ventana de la aplicación, lo que podría causar un efecto de paralaje en el que la ubicación del puntero del ratón dentro de la ventana de la máquina virtual o del escritorio remoto se desplaza del puntero del ratón del host.

Wayland resuelve esto añadiendo extensiones de protocolo para Wayland y XWayland. Es necesario añadir soporte para estas extensiones a los compositores de Wayland. En el caso de los clientes nativos de Wayland, los kits de herramientas de widgets utilizados (por ejemplo, GTK, Qt) deben soportar estas extensiones o las propias aplicaciones si no se utiliza ningún kit de herramientas de widgets. En el caso de las aplicaciones Xorg, no se necesitan cambios en las aplicaciones o en los kits de herramientas de widgets ya que el soporte de XWayland es suficiente.

Estas extensiones ya están incluidas en wayland-protocols, y soportadas por xorg-xwayland.

Las extensiones relacionadas son:

  • Protocolo de agarre del teclado de XWayland
  • Protocolo de inhibición de accesos directos del compositor
  • Protocolo de punteros relativos
  • Protocolo de restricciones de punteros

Soporte de los compositores de Wayland:

  • Mutter, el compositor de GNOME desde la versión 3.28
  • wlroots soporta relative-pointer y pointer-constraints

Soporta kits de herramientas de widgets:

  • GTK desde la versión 3.22.18.

Ver también

  • Documentación de Wayland en línea
  • Oficial Wayland Git Repo
  • Fedora:Cómo depurar los problemas de Wayland
  • Impresionantes proyectos de Wayland
  • Temas del cursor
  • Discusión en el foro de Arch Linux
  • Guía de migración a i3 – Aplicaciones X11 comunes utilizadas en i3 con alternativas a Wayland

Deja una respuesta

Tu dirección de correo electrónico no será publicada.