Wayland (Español)
Wayland es un protocolo de servidor gráfico. Tiene como objetivo volverse el sucesor del X Window System. Puede consultar una comparación entre Wayland y Xorg en Wikipedia (en Ingl.
Los servidores gráficos que usan el protocolo de Wayland son denominados compositores debido a que también actúan como un gestor de composición de ventanas. Debajo puede encontrar una lista de compositores de Wayland.
Para obtener una ejecución fluida y compatibilidad con aplicaciones nativas de X11 puede usar Xwayland, que proveé un servidor X en Wayland.
Requisitos
La mayoría de los compositores de Wayland sólo funcionan en sistemas que utilicen Kernel mode setting. Wayland por sí mismo no proporciona un entorno gráfico; para ello necesita un compositor (vea la siguiente sección), o un entorno de escritorio que incluya un compositor (por ejemplo GNOME (Español) o KDE (Español)#Plasma).
Para que el controlador de la GPU y el compositor Wayland sean compatibles, ambos deben soportar la misma API de búfer. Hay dos APIs principales: GBM y EGLStreams.
API de búfer | Soporte de controlador para GPU | Soporte de compositor Wayland |
---|---|---|
GBM | Todos excepto NVIDIA < 495* | Todos |
EGLStreams | NVIDIA | GNOME (Español) |
- * NVIDIA ≥ 495 soporta tanto EGLStreams como GBM.[1]
Desde que NVIDIA introdujo el soporte de GBM, muchos compositores (incluyendo Mutter y KWin) empezaron a usarlo por defecto para NVIDIA ≥ 495. GBM se considera generalmente mejor con un soporte más amplio, y EGLStreams sólo tenía soporte porque NVIDIA no proporcionaba ninguna forma alternativa de utilizar sus GPUs bajo Wayland con sus controladores propietarios. Además, KWin abandonó el soporte para EGLStreams después de que GBM fuera introducido en NVIDIA.
Si utiliza un entorno de escritorio o compositor popular y una GPU aún soportada por NVIDIA, lo más probable es que ya utilice el backend GBM. Para comprobarlo, ejecute journalctl -b 0 --grep "renderer for"
. Para forzar GBM como backend, asigne las siguientes variables de entorno:
GBM_BACKEND=nvidia-drm __GLX_VENDOR_LIBRARY_NAME=nvidia
Compositores
Consulte Window manager (Español)#Tipos para las diferencias entre Mosaico (tiling) y Apilamiento (stacking).
Mosaico
- Hyprland — Un compositor de mosaico dinámico de Wayland que no hace sacrificios en su apariencia.
- japokwm — Compositor de mosaico dinámico de Wayland con la idea de crear disposiciones (layouts), basado en wlroots.
- niri — Un compositor de mosaico scrollable de Wayland.
- Polonium — Un sucesor espiritual de Bismuth que coloca ventanas en mosaico en KDE 6.
- Qtile — Un gestor de ventanas en mosaico completo y hackeable, y un compositor Wayland escrito y configurado en Python.
- river — Compositor de mosaico dinámico inspirado por dwm y bspwm (Español).
- SwayFx — Sway, ¡con efectos visuales!
- Velox — Gestor de ventanas sencillo basado en swc, inspirado por dwm y xmonad.
- Vivarium — Compositor de mosaico dinámico de Wayland que usa wlroots, con la semántica del entorno de escritorio inspirada por xmonad.
Apilamiento
- Enlightenment — Véase Enlightenment#Manually. Más información: [2] [3]
- hikari — Compositor inspirado por cwm que es desarrollado en FreeBSD aunque también soporta Linux.
- https://hikari.acmelabs.space/[enlace roto 2024-11-06] || hikariAUR
- KDE KWin — Vea KDE (Español)#Iniciar Plasma.
- Liri Shell — Parte de Liri,escrito usando QtQuick y QtCompositor como compositor para Wayland.
- labwc — Compositor basado en wlroots inspirado en Openbox.
- Mutter — Véase GNOME (Español)#Inicio.
- wayfire — Compositor 3D inspirado por Compiz y basado en wlroots.
- https://wayfire.org/ || wayfireAUR
- Weston — Compositor de Wayland diseñado para ser correcto, fiable, predecible y eficaz.
- wio — Compositor basado en wlroots que busca replicar la apariencia del escritorio Rio de Plan 9.
Otros
- Cage — Muestra en modo pantalla completa una única aplicación, como un kiosko.
- nwg-shell — Una shell basada en GTK para los compositores sway y Hyprland de Wayland.
- kiwmi — Un compositor de Wayland completamente programable.
- phoc — Un diminuto compositor basado en wlroots para dispositivos móviles.
Algunos de los mencionados soportan gestores de pantalla. Verifique /usr/share/wayland-sessions/compositor.desktop
para saber cómo son iniciados.
Gestores de inicio de sesión
Los gestores de pantalla, o gestores de inicio de sesión, listados debajo soportan el inicio de compositores de Wayland.
Nombre | ¿Se ejecuta en Wayland? | Descripción |
---|---|---|
emptty | No | Un simple gestor de inicio de sesión para la TTY. |
GDM | Sí | Gestor de inicio de sesión de GNOME (Español). |
greetd | Al usar un greeter compatible con Wayland | Demonio de inicio de sesión mínimo y flexible. |
lemurs | No | Gestor de inicio de sesión con una interfáz de usuario en terminal (TUI) escrita en Rust. |
LightDM | No | Gestor de inicio de sesión multiescritorio. |
Ly | No | Gestor de inicio de sesión con una TUI escrita en C. |
SDDM | Sí | Gestor de inicio de sesión basado en QML. |
tbsm | No | Un lanzador de sesiones simple con una interfaz de usuario por consola (CLI) escrito en bash. |
uwsmAUR | No | Administrador de sesión y de inicio automático de XDG para compositores independientes que aprovecha los mecanismos de Systemd. |
Xwayland
Xwayland[enlace roto 2024-10-12] es un servidor X que se ejecuta dentro de Wayland y proveé compatibilidad para aplicaciones nativas de X11 que aún no tienen soporte en Wayland. Para usarlo instale el paquete xorg-xwayland.
Xwayland se inicia a través de un compositor, por lo que debe consultar la documentación del compositor elegido para comprobar la compatibilidad con Xwayland y las instrucciones sobre cómo iniciar Xwayland.
- Seguridad: Xwayland es un servidor X, por lo que no proveé las características de seguridad de Wayland
- Rendimiento: Xwayland tiene un rendimiento similar a X11. En algunos casos puede observar un rendimiento deteriorado, especialmente con tarjetas gráficas NVIDIA.
- Compatibilidad: Xwayland no es totalmente compatible con X11. Algunas aplicaciones pueden no funcionar correctamente en Xwayland.
Controlador de NVIDIA
Se requiere habilitar DRM KMS. Puede encontrar información adicional en la documentación oficial independientemente de su gestor de pantalla (por ejemplo GDM).
Consola de depuración de Kwin en Wayland
Si usa kwin, ejecute el siguiente comando para saber qué ventanas utilizan Xwayland o Wayland nativo, superficies, entradas de eventos, contenidos del portapapeles y más.
$ qdbus6 org.kde.KWin /KWin org.kde.KWin.showDebugConsole
Detectar visualmente aplicaciones de Xwayland
Para determinar si una aplicación se ejecuta usando Xwayland puede iniciar extramausAUR. Mueva el cursor del ratón sobre la ventana de la aplicación, si el ratón rojo se mueve la aplicación funciona vía Xwayland.
Alternativamente puede usar xorg-xeyes y ver si los ojos se mueven cuando pasa el cursor del ratón sobre la ventana de la aplicación.
Otra opción es ejecutar xwininfo (de xorg-xwininfo) en una terminal: al pasar el cursor del ratón sobre una ventana de Xwayland el puntero debería convertirse en un símbolo +. Si da click en la ventana se mostrará información y finalizará su ejecución. Puede usar Ctrl+C
para terminar el comando.
También es posible utilizar xlsclients (de xorg-xlsclients). Para listar todas las aplicaciones ejecutándose mediante Xwayland ejecute la orden xlsclients -l
.
Bibliotecas GUI
Consulte los detalles en la página oficial[enlace roto 2024-10-12].
GTK
Los paquetes gtk3 y gtk4 tienen el backend de Wayland habilitado. GTK usará por defecto el backend de Wayland, aunque es posible forzar el uso de Xwayland modificando la variable de entorno: GDK_BACKEND=x11
.
Para problemas relacionado con el tema de las aplicaciones consulte GTK (Español)#Backend de Wayland.
Qt
Para habilitar el soporte de Wayland en Qt (Español) 5 o 6, instale respectivamente qt5-wayland o qt6-wayland. Las aplicaciones Qt de su sistema utilizarán Wayland en una sesión de Wayland.
Aunque es debería de ser necesario, para ejecutar una aplicación de Qt explcon el complemento de Wayland [4], utilice la variable de entorno -platform wayland
o QT_QPA_PLATFORM=wayland
.
Para forzar el uso de X11 en una sesión de Wayland use QT_QPA_PLATFORM=xcb
. Esto puede ser necesario para aplicaciones propietarias que no usan la implementación de Qt del sistema, como zoomAUR.
QT_QPA_PLATFORM="wayland;xcb"
permite a Qt usar el complemento xcb (X11) si Wayland no está disponible [5].
En algunos compositores, por ejemplo sway (Español), las aplicaciones Qt que se ejecutan de forma nativa pueden tener funciones faltantes. Por ejemplo, KeepassXC no podrá minimizarse a la bandeja de estado. Esto puede resolverse instalando qt5ct y asignando QT_QPA_PLATFORMTHEME=qt5ct
antes de ejecutar la aplicación.
Clutter
El conjunto de herramientas de Clutter tiene un backend Wayland que permite que se ejecute como cliente de Wayland. El backend está activado en el paquete clutter.
Para ejecutar una aplicación de Clutter en Wayland, establezca CLUTTER_BACKEND=wayland
.
SDL2
Para ejecutar una aplicación de SDL2 en Wayland, establezca SDL_VIDEODRIVER=wayland
.
SDL_VIDEODRIVER="wayland,x11"
permite a SDL2 usar el controlador de video de X11 en caso de que Wayland no esté disponible [6]. También puede que le sea útil instalar libdecor para habilitar decoraciones de las ventanas (como en GNOME por ejemplo).
GLFW
El paquete glfw tiene soporte para Wayland, utiliza el backend de Wayland si la variable de entorno XDG_SESSION_TYPE
está asignada a wayland
y la persona desarrolladora de la aplicación no ha configurado un backend específico.
Consulte el código fuente para más información.
GLEW
El paquete glew-waylandAUR aún no funciona con la mayoría de aplicaciones basadas en GLEW, por lo que la única opción es usar Xwayland. Véase FS#62713.
EFL
EFL tiene soporte completo para Wayland. Para ejecutar una aplicación de EFL en Wayland, vea la página del proyecto[enlace roto 2024-10-12] de Wayland.
winit
Winit es una biblioteca de manejo de ventanas escrita en Rust. Por defecto usará el backend de Wayland, aunque es posible forzar el uso de Xwayland modificando las variables de entorno:
- Para versiones anteriores a 0.29.2 asigne
WINIT_UNIX_BACKEND=x11
. - Para la versión 0.29.2 y posteriores desactive
WAYLAND_DISPLAY
, lo cual obliga el uso de X utilizando la variableDISPLAY
. [7]
Electron
La compatibilidad con Wayland puede activarse mediante opciones de línea de comandos por aplicación o de forma más global mediante un archivo de configuración.
Para determinar qué versión de electron usa, consulte [8].
Variables de entorno
Las aplicaciones que usan la versión 28 de Electron y posteriores, pueden usar la variable de entorno ELECTRON_OZONE_PLATFORM_HINT al asignarla a auto
o wayland
.
Banderas de línea de comandos
A diferencia de Chromium, en el navegador que está basado Electron, las aplicaciones de Electron no permiten la captura de pantalla con WebRTC a través de PipeWire de forma predeterminada. Por lo tanto, se recomienda utilizar --enable-features=WebRTCPipeWireCapturer
para evitar problemas de captura de pantalla en Wayland. La captura se basa en xdg-desktop-portal.
Para utilizar aplicaciones basadas en electron de forma nativa en Wayland cuando el uso de la variable de entorno no es deseable o factible, es posible añadir --ozone-platform-hint=auto
en Electron 20+.
Los casos de falta de barras superiores se pueden resolver mediante el uso de: --enable-features=WaylandWindowDecorations
. Esto suele ser necesario en GNOME (Español) (soportado desde electron17).
Puede asignar de forma más persistente estas banderas al modificar el archivo .desktop de una aplicación al añadirlas al final de la línea Exec=
, o utilizando los archivos de configuración mencionados a continuación.
Archivo de configuración
Los paquetes Electron leen los archivos ~/.config/electronXX-flags.conf
, donde XX es la versión de Electron, o recurren al archivo compartido ~/.config/electron-flags.conf
, si el archivo versionado no se encuentra presente.
De las banderas coloque una por linea:
~/.config/electron-flags.conf
--enable-features=WaylandWindowDecorations --ozone-platform-hint=auto
Versiones anteriores de Electron
electron25-flags.conf
solamente funciona para la versión 25 de Electron. Versiones anteriores pueden configurarse usando su propio archivo electron<version>-flags.conf
.
Versiones más anteriores pueden requerir banderas diferentes, dependiendo en la versión correspondiente de Chromium. Por ejemplo, las siguientes banderas funcionan en Electron 13:
~/.config/electron13-flags.conf
--enable-features=UseOzonePlatform --ozone-platform=wayland
Java
La implementación de código abierto de la plataforma OpenJDK de Java, no cuenta con soporte nativo para Wayland. Será hasta Wakefield, que el proyecto busque implementar OpenJDK en Wayland, mientras tanto puede usar Xwayland.
Véase Debian:Wayland#Java Programs (supported since OpenJDK 16?):
- Desde OpenJDK 16, la JRE puede usar de forma dinámica GTK3 (que soporta Wayland), aparentemente esto tiene soporte de acuerdo a esta discusión.
- La
_JAVA_AWT_WM_NONREPARENTING
variable de entorno puede ser establecida a "1" para solucionar cuando una aplicación inicia mostrando una pantalla negra.
Consejos y Trucos
Automatización
-
ydotool (ydotool) - Herramienta de línea de comandos de automatización (no limitada a wayland). Habilite/inicie la unidad de usuario
ydotool.service
. Véase ydotool(1), ydotoold(1). - wtype (wtype) - Herramienta similar a xdotool para Wayland. Consulte wtype(1).
- keyboard - Biblioteca de Python que funciona en Windows y Linux con soporte experimental para OS X. También véase la biblioteca mouse.
- wlrctl (wlrctlAUR) - Una utilidad de linea de comandos para extensiones de wlroots (soporta foreign-toplevel-management, virtual-keyboard, virtual-pointer).
Reasignación de teclas de teclado o ratón
Véase Input remap utilities.
Grabar ventanas de Wayland con aplicaciones X11
Consulte Screen capture#Screencast Wayland windows with X11 applications (en Inglés).
Solución de problemas
Corrección de color
Véase Backlight#Color correction.
Movimiento lento, fallos gráficos y bloqueos
Usuario de Gnome-shell pueden experimentar errores de pantalla cuando cambian a Wayland desde X. Una causa puede ser que la variable CLUTTER_PAINT=disable-clipped-redraws:disable-culling
haya sido asignada para la sesión Xorg de Gnome-shell. Para mitigar este error simplemente intente eliminarla de /etc/environment
u otros archivos rc.
Pantalla remota
- wlroots (usado por sway) ofrece un backend VNC mediante wayvnc, desde la versión 0.10. el backend RDP ha sido eliminado [9].
- mutter habilita escritorio remoto cuando se compila, consulte [10] y gnome-remote-desktop para más detalles.
-
krfb ofrece un servidor VNC para kwin.
krfb-virtualmonitor
puede ser usado para configurar un dispositivo adicional como una pantalla adicional. - Hubo una fusión FreeRDP en Weston en 2013, que lo habilita usando una bandera de compilación. El paquete weston usa esta bandera desde la versión 6.0.0.
-
waypipeAUR (o waypipe-gitAUR) es un proxy transparente para aplicaciones de Wayland, con un wrapper para ejecutarlo en SSH (Español).
- Por ejemplo, para lanzar una instancia remota de KDE kcalc en Plasma:
$ waypipe ssh example.local env QT_QPA_PLATFORM=wayland-egl QT_QPA_PLATFORMTHEME=KDE dbus-launch kcalc
Detección de entrada en juegos, escritorio remoto y ventanas de máquinas virtuales
A diferencia de Xorg, Wayland no permite la captura exclusiva de dispositivos de entrada, también conocida como captura activa o explícita (por ejemplo teclado, ratón), en su lugar, depende del compositor de Wayland enviar los atajos de teclado y confinar el apuntador del ratón a la ventana de la aplicación.
Este cambio en la captura de entrada irrumple el comportamiento de las aplicaciones actuales, lo que significa:
- Las combinaciones de teclas de acceso rápido y los modificadores serán capturados por el compositor y no se enviarán al escritorio remoto ni a las ventanas de la máquina virtual.
- El puntero del mouse no estará restingido a la ventana de la aplicación, lo cual puede causar un efecto de paralaje donde la ubicación del puntero dentro de la ventana de la máquina virtual o escritorio remoto es desplazada con respecto al puntero de la máquina anfitriona.
Wayland soluciona esto al agregar extensiones de protocolo para Wayland y Xwayland. El soporte para dichas extensiones debe de ser incluido a los compositores de Wayland. En el caso de los clientes nativos, los toolkits (por ejemplo, GTK, Qt) deben soportar estas extensiones, o las aplicaciones mismas si no se usa toolkit alguno. Para las aplicaciones de Xorg o toolkits no es necesario cambio alguno, pues el soporte de Xwayland es suficiente.
Estas extensiones son incluidas en wayland-protocols, y soportadas por xorg-xwayland.
Las extensiones relacionadas son:
- Protocolo de captura de teclado de Xwayland
- Protocolo inhibidor de atajos de teclado del compositor
- Protocolo del apuntador relativo
- Protocolo de limitación de punteros
Compositores que soportan Wayland:
- El compositor de GNOME (Español), Mutter desde la versión 3.28
- wlroots soporta protocolo del apuntador relativo y limitación de punteros
- Kwin
Toolkits soportados:
- GTK desde la versión 3.22.18.
Temas GTK no funcionan
Véase https://github.com/swaywm/sway/wiki/GTK-3-settings-on-Wayland.
Evitar usar los módulos de NVIDIA
Asigne __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json
como variable de entorno antes de ejecutar un compositor de Wayland como sway (Español).
Ampliación/escalamiento de superficies
La ampliación de pantalla aún no está resuelta, se ha fusionado un pull request a mediados de 2022 proporcionando al protocolo wp-surface-scale.
Véase también
- Documentación de Wayland online
- Repositorio oficial
- Fedora:How to debug Wayland problems
- Are we Wayland yet?
- Awesome Wayland projects
- Cursor themes (Español)
- Foro de discusión de Arch Linux
- Guía de migración de i3 - Aplicaciones comunes de X11 con alternativas en Wayland
- Wayland Explorer - Una mejor forma de leer documentación de Wayland
- ¿Cómo saber si una aplicación usa Xwayland?