Wayland (Español)

Esta traducción de Wayland fue revisada el 2024-06-04. Si existen cambios puede actualizarla o avisar al equipo de traducción.

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

Cagebreak — Basado en cage, inspirado por ratpoison.

https://github.com/project-repo/cagebreak || cagebreak^AUR

dwl — Compositor de Wayland similar a dwm basado en wlroots.

https://codeberg.org/dwl/dwl || dwl^AUR

Hyprland — Un compositor de mosaico dinámico de Wayland que no hace sacrificios en su apariencia.

https://hyprland.org || hyprland

japokwm — Compositor de mosaico dinámico de Wayland con la idea de crear disposiciones (layouts), basado en wlroots.

https://github.com/werererer/japokwm || japokwm-git^AUR

niri — Un compositor de mosaico scrollable de Wayland.

https://github.com/YaLTeR/niri/ || niri

Polonium — Un sucesor espiritual de Bismuth que coloca ventanas en mosaico en KDE 6.

https://github.com/zeroxoneafour/polonium || kwin-polonium^AUR

Qtile — Un gestor de ventanas en mosaico completo y hackeable, y un compositor Wayland escrito y configurado en Python.

https://github.com/qtile/qtile || qtile

river — Compositor de mosaico dinámico inspirado por dwm y bspwm (Español).

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

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

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

SwayFx — Sway, ¡con efectos visuales!

https://github.com/WillPower3309/swayfx || swayfx^AUR

Velox — Gestor de ventanas sencillo basado en swc, inspirado por dwm y xmonad.

https://github.com/michaelforney/velox || velox-git^AUR

Vivarium — Compositor de mosaico dinámico de Wayland que usa wlroots, con la semántica del entorno de escritorio inspirada por xmonad.

https://github.com/inclement/vivarium || vivarium-git^AUR

Apilamiento

Enlightenment — Véase Enlightenment#Manually. Más información: [2] [3]

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

hikari — Compositor inspirado por cwm que es desarrollado en FreeBSD aunque también soporta Linux.

https://hikari.acmelabs.space/ || hikari^AUR

KDE KWin — Vea KDE (Español)#Iniciar Plasma.

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

Liri Shell — Parte de Liri,escrito usando QtQuick y QtCompositor como compositor para Wayland.

https://github.com/lirios/shell || liri-shell-git^AUR

labwc — Compositor basado en wlroots inspirado en Openbox.

https://github.com/labwc/labwc || labwc-git^AUR

Mutter — Véase GNOME (Español)#Inicio.

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

wayfire — Compositor 3D inspirado por Compiz y basado en wlroots.

https://wayfire.org/ || wayfire^AUR

Weston — Compositor de Wayland diseñado para ser correcto, fiable, predecible y eficaz.

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

wio — Compositor basado en wlroots que busca replicar la apariencia del escritorio Rio de Plan 9.

https://gitlab.com/Rubo/wio || wio-wl^AUR

Otros

Cage — Muestra en modo pantalla completa una única aplicación, como un kiosko.

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

nwg-shell — Una shell basada en GTK para los compositores sway y Hyprland de Wayland.

https://github.com/nwg-piotr/nwg-shell || nwg-shell

kiwmi — Un compositor de Wayland completamente programable.

https://github.com/buffet/kiwmi || kiwmi-git^AUR

phoc — Un diminuto compositor basado en wlroots para dispositivos móviles.

https://gitlab.gnome.org/World/Phosh/phoc || phoc

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.
uwsm^AUR	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.

Nota:

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

Nota: Los controladoes de NVIDIA anteriores a la versión 470 (es decir nvidia-390xx-dkms^AUR) no soportan aceleración por hardware para Xwayland, causando que las aplicaciones no nativas de Wayland tengan bajo desempeño en la sesión de Wayland.

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 extramaus^AUR. 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 zoom^AUR. 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-wayland^AUR 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 variable DISPLAY. [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].

Nota: En Plasma algunas aplicaciones pueden utilizar un ícono de ventana incorrecto (como el de defecto de Wayland) y usar el ícono correcto en la barra de tareas. Para corregirlo, intente crear una regla especial de aplicación o ventana, para forzar el desktop file en dichas aplicaciones.

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.

Nota: Algunos paquetes, no envían las banderas a Electron, por lo que será necesaria una solución desde el equipo de desarrollo.

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

Nota: Estos archivos de configuración sólo funcionan con los paquetes de Electron en los repositorios oficiales y los paquetes que los usan. No funcionan para los paquetes que tienen su propia versión de Electron, como slack-desktop^AUR. Aveces existen algunas aternativas como slack-electron^AUR.

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 (wlrctl^AUR) - 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.
waypipe^AUR (o waypipe-git^AUR) 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:

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
- KDE#X11 shortcuts conflict on Wayland
- Bloqueo de los atajos de teclado

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