Distribuciones

GNOME 51.1: mejoras en drag and drop entre Wayland y Xwayland (y más bugfixes)

Tengo un par de workstations con Fedora 45 que viven entre Wayland nativo y unas cuantas apps en Xwayland — un editor gráfico viejo, un par de herramientas de monitoreo que todavía no migran a GTK4, y un navegador propietario que no quiero reemplazar todavía. Cada vez que arrastro un archivo entre una ventana Wayland y otra Xwayland, la operación completa o se cuelga medio segundo o me tira un cursor fantasma. Por eso, cuando vi el anuncio de GNOME 51.1 el 18 de octubre de 2026, lo primero que leí fue la línea del drag and drop entre Wayland y Xwayland. La noticia corta del anuncio oficial del GNOME Release Team dice que es “un bugfix aburrido, seguro de actualizar”, y por una vez eso no me preocupa: GNOME 50 a 51 ya rompió cosas importantes, así que un punto que se concentra en arreglar lo roto es exactamente lo que quiero.

GNOME 51.1 es la primera release de mantenimiento de GNOME 51 “A Coruña” (publicado el 16 de septiembre). No trae features nuevas de cara al usuario, pero toca Mutter, Nautilus, Orca, Epiphany, Settings, Maps, System Monitor e Initial Setup con una lista larga de bugfixes. Lo que más me interesa, y lo que más le va a interesar a quien use un setup mixto Wayland + Xwayland, es el rework del protocolo de drag and drop en Mutter. El resto del post lo desgloso.

TL;DR — Lo que vas a tener al final

  • Tiempo de setup: 5 minutos si usas una distro con GNOME 51; el upgrade llega por el canal estable de tu distro en días.
  • Requisitos: Cualquier distribución Linux con GNOME 51 instalado (Fedora 45, Ubuntu 26.10, openSUSE Tumbleweed reciente, Arch, etc).
  • Resultado: Bugfix point release — drag and drop funcional entre Wayland y Xwayland, Nautilus más estable, Orca con soporte GPaste3, frame clock sin throttling agresivo en power saving.
  • Troubleshooting: Si el drag and drop sigue fallando, verificar `MOZ_ENABLE_WAYLAND=1` en apps Qt/Chromium y revisar `journalctl -b -u gdm` para errores de Mutter.

Qué es GNOME 51.1 y por qué te importa

El proyecto GNOME sigue una cadencia semestral para releases mayores (la 51 salió el 16 de septiembre de 2026, bautizada “A Coruña” por la ciudad gallega que acogió GUADEC 2026) y publica entre tres y cinco point releases de mantenimiento entre cada major. GNOME 51.1 es la primera de esa serie, así que trae la cosecha inicial de bugs que se reportan cuando miles de personas empiezan a usar la versión nueva en producción.

Para un sysadmin o un usuario de escritorio Linux, la diferencia entre “esperar al 51.2” y “actualizar hoy al 51.1” suele ser marginal. Pero hay dos razones para no postergarlo:

  • El rework de drag and drop Wayland ↔ Xwayland en Mutter resuelve un bug que ha molestado a cualquiera con un setup mixto desde hace meses. Si arrastras un PDF desde Nautilus a una app en Xwayland (o al revés), el comportamiento era errático: a veces pegaba, a veces no, a veces pegaba el contenido del portapapeles equivocado.
  • Mutter 51.1 también corrige el throttling del frame clock en power saving: el compositor puede dejar de actualizar frames cuando la laptop está en batería para ahorrar energía, pero en 51.0 el throttle era demasiado agresivo y producía stutters perceptibles. Si usas la laptop en batería con Wayland, vas a sentir el cambio sin necesidad de benchmark.

El resto de cambios son más nicho: mejoras en Orca (lector de pantalla), correcciones de memory leaks en Nautilus, ajustes de UI en Settings, y soporte para GPaste3 en Orca. Si tu flujo depende de alguna de estas piezas, el 51.1 te va a ahorrar trabajo.

Cambios clave en Mutter: drag and drop Wayland y Xwayland

Mutter es el compositor y window manager de GNOME. Cada point release incluye ajustes al protocolo Wayland, y en 51.1 el cambio más visible es el rework del drag and drop entre clientes nativos Wayland y clientes Xwayland (apps X11 que corren a través del bridge Xwayland porque todavía no tienen soporte nativo).

El problema histórico era que el protocolo wl_data_device de Wayland no tiene un equivalente directo al drag and drop X11 clásico. Mutter tenía que traducir entre los dos modelos, y la traducción tenía holes:

  • Selección con el mismo serial: Mutter 51.0 fallaba al cambiar la selección del portapapeles dentro de la misma “operación” de drag, lo que producía que el destino recibiera el MIME type equivocado. Mutter 51.1 permite cambiar selecciones con el mismo serial sin abortar el drag.
  • MRU order en ventanas sticky: cuando una ventana se vuelve “sticky” (presente en todos los workspaces), Mutter 51.0 rompía el orden de más-recientemente-usado. 51.1 preserva el orden, que es lo que apps multitarea como los docks necesitan.
  • Drag de Wayland a Xwayland: el rework permite que el origen Wayland anuncie sus MIME types correctamente al destino X11, y viceversa. Antes había un mismatch en el formato de text/uri-list que rompía drops de archivos en apps como Electron o Chromium cuando se cargaban en modo X11.
  • Fallback a Xcursor: si un cursor implementation en Wayland no expone un cursor específico, Mutter 51.1 ahora cae al cursor X11 clásico vía Xwayland. Antes el cursor simplemente desaparecía.

Para verificar que el drag and drop está usando el path correcto, abre una terminal y monitoriza el log de Mutter mientras arrastras:

journalctl -f -u gnome-shell --no-pager | grep -i 'data.device|dnd|drag'

Si ves líneas del tipo wl_data_device enter seguidas de wl_data_device motion y wl_data_device drop con un source que termina en xwayland, el bridge está funcionando. Si no ves esas líneas, probablemente estás corriendo la app en modo X11 nativo y Mutter no interviene en absoluto — eso es otra capa del problema, no un bug de 51.1.

Nautilus y los file choosers GTK4

El administrador de archivos (Nautilus) recibió un lote de bugfixes en 51.1. Los más relevantes para sysadmins que automatizan con scripts:

  • Reutilización de tabs al abrir desde GNOME Shell: cuando haces clic derecho en un archivo en el escritorio y seleccionas “Abrir carpeta contenedor”, Nautilus antes abría una ventana nueva siempre. 51.1 reutiliza la tab activa si existe, evitando multiplicar ventanas.
  • Indicador de archivo no escribible: el emblema “read-only” ahora aparece correctamente cuando el filesystem lo reporta. Antes había un race condition entre el mount y el primer escaneo que mostraba archivos como escribibles cuando no lo eran.
  • Diálogo de Properties demasiado pequeño: bug clásico de GTK4 donde el diálogo abría con un tamaño mínimo que no respetaba el contenido. 51.1 fuerza un tamaño mínimo usable.
  • Replace button enfocado por defecto en el diálogo de conflicto (cuando copias un archivo que ya existe). Antes había que tabular hasta el botón, ahora Enter funciona directamente. Pequeño detalle, gran ahorro de tiempo cuando haces batch renames.
  • Thumbnails cuadrados en Properties: el panel mostraba thumbnails con aspect ratio libre, deformándolas. Ahora se hace fit-to-square.
  • Memory leaks en extensiones audio/video: si usas Nautilus con previewers de audio/video activados, había un leak en el cache que podía mantener cientos de MB ocupados después de navegar carpetas grandes. 51.1 corrige varios de esos leaks.

El cambio que más workflow cambia es el respeto del setting de sorting default del GTK4 file chooser. Antes Nautilus imponía su propio orden (nombre ascendente), ignorando la configuración global de GTK. 51.1 respeta el setting del sistema:

# Verificar el setting global de GTK4 file chooser
gsettings get org.gtk.gtk4.Settings.FileChooser sort-directories-first
gsettings get org.gtk.gtk4.Settings.FileChooser default-sort-folder

Si quieres que Nautilus ordene por fecha de modificación al abrir un folder (común para sysadmins revisando logs), setea default-sort-folder a modified:

gsettings set org.gtk.gtk4.Settings.FileChooser default-sort-folder 'modified'

Orca, GPaste3 y accesibilidad

Orca, el lector de pantalla de GNOME, tuvo una actualización sustancial en 51.1. Si dependes de Orca para trabajar, este es probablemente el point release que más vale la pena de toda la serie.

Los cambios más prácticos:

  • Soporte para GPaste3 D-Bus interface: GPaste es el clipboard manager de GNOME. Antes Orca solo podía leer del clipboard del sistema; ahora accede directamente al historial de GPaste vía D-Bus, lo que permite navegar el historial de portapapeles desde el lector de pantalla.
  • Presentación de tablas y grids: cuando el foco y la selección no coinciden (común en hojas de cálculo web), Orca 51.0 a veces repetía la celda mal. 51.1 distingue entre foco y selección, anunciando la celda correcta.
  • ARIA combo boxes sin valuetext: fallback al texto visible del combo box, en vez de anunciar “combobox vacío” como antes.
  • Caret-moved events filtrados: Orca ignora eventos de movimiento de caret de elementos que están expuestos al lector pero marcados como ignorados, evitando lecturas duplicadas.
  • Recuperación de foco en objetos destruidos: si la app destruye el objeto con foco, Orca 51.0 perdía el contexto por un momento. 51.1 prefiere el evento pending focus, recuperando más rápido.
  • Indicadores braille stale: cuando mueves el caret, Orca limpia los indicadores de selección braille obsoletos. Antes se quedaban pegados hasta el siguiente refresh.

Si trabajas con Orca y quieres verificar que el soporte GPaste3 está activo, abre el monitor D-Bus mientras arrastras un item al clipboard:

# Monitorear signals de GPaste
dbus-monitor --session "interface='org.gnome.GPaste3.*'" | head -20

Deberías ver señales ItemAdded cada vez que copias algo. Si no aparecen y GPaste está corriendo (gpaste-client check), el bridge con Orca no se inicializó, y toca reiniciar la sesión GNOME.

Otros cambios: Epiphany, Settings, Maps, System Monitor

El resto de la changelog toca piezas más pequeñas pero igual de importantes para flujos específicos:

  • Epiphany (GNOME Web): la búsqueda de bookmarks ahora funciona correctamente cuando estás viendo un tag específico. Antes devolvía resultados de toda la colección, no filtrados por el tag activo.
  • GNOME Settings: ajustes de UI y bugfixes en los paneles de Accessibility, Keyboard, Location, Mobile Networks, Printers y System. El más visible: el panel de Keyboard ya no pierde el foco al cambiar entre layouts.
  • GNOME Maps: elimina algunos warnings de GTK al renderizar itinerarios de transporte público. No es un fix funcional, pero reduce el ruido en journalctl.
  • GNOME System Monitor: recuerda la posición de la ventana entre sesiones en X11. (Sí, suena raro en 2026, pero sigue siendo relevante para los que corren X11 sessions por compatibilidad con apps específicas.)
  • GNOME Initial Setup: explícitamente carga el secret service (oo7-daemon) en la sesión, evitando el bug clásico donde las apps no podían guardar credenciales en el keyring tras el primer login.
  • GNOME Shell: mejorada la posición del reloj en la lock screen, mejorados los mount notifications, y corregido el bug de Quick Settings que bloqueaba el “direct scanout” (salida directa del framebuffer sin pasar por el compositor, usada en fullscreen para reducir input lag).

El fix de Initial Setup es pequeño pero molesto: si tenías que correr systemctl --user restart oo7-daemon después de cada login para que funcionaran apps como Remmina o Seahorse, eso ya no es necesario en 51.1.

Cómo instalar o actualizar a GNOME 51.1

El método depende de tu distro. GNOME 51.1 es un update de paquetes estándar, no requiere reinstalación.

Fedora 45 (Workstation):

sudo dnf upgrade --refresh
# Reiniciar para que Mutter cargue la versión nueva
sudo systemctl reboot

Ubuntu 26.10 (Stonking Stingray) y backports en 26.04:

sudo apt update && sudo apt upgrade
sudo systemctl reboot

Arch Linux y derivadas (Manjaro, Endeavour):

sudo pacman -Syu
sudo systemctl reboot

openSUSE Tumbleweed:

sudo zypper dup
sudo systemctl reboot

Si quieres verificar la versión exacta de Mutter instalada sin reiniciar (es útil para troubleshooting en sesiones remotas), puedes revisar el binario o usar:

mutter --version
gnome-shell --version

Problemas conocidos y cómo mitigarlos

Aunque el anuncio oficial lo describe como un update “aburrido y seguro”, siempre hay casos donde un point release expone un bug en interacción con hardware o drivers específicos. Lo que he visto documentado hasta ahora:

  • NVIDIA propietarios con driver < 550: el rework del cursor fallback a Xcursor en Mutter 51.1 puede entrar en conflicto con el driver NVIDIA propietario clásico. Si tu cursor desaparece aleatoriamente, prueba a forzar el cursor nativo de GNOME con gsettings set org.gnome.desktop.interface cursor-size 24 y reporta al equipo de NVIDIA.
  • Apps Qt5 sin port Qt6: apps como Krita, KeePassXC o VirtualBox Manager usan Qt5 y arrastran contra Xwayland por default. Si el drag and drop sigue fallando después de 51.1, fuerza el uso del platform plugin Wayland explícitamente: QT_QPA_PLATFORM=wayland krita.
  • Throttling del frame clock en laptops híbridas: aunque Mutter 51.1 reduce el throttle, algunas laptops con Intel + NVIDIA Optimus todavía reportan stutters al cambiar entre GPUs. El workaround clásico sigue siendo desactivar el mode-switching dinámico y fijar la GPU activa desde la BIOS o via prime-select.
  • GNOME Extensions incompatibles: si usas muchas extensions, es posible que alguna no haya actualizado su declaración de soporte para GNOME 51 todavía. El soporte de gnome-autoar para extraer extensions ayuda a la mayoría, pero no a todas. Revisa extensions.gnome.org y desactiva las que reporten incompatibilidad.

Si encuentras un bug nuevo, repórtalo en el issue tracker de GNOME Shell o en el de Mutter según corresponda. Incluye la salida de gnome-shell --version y los logs con journalctl -b -u gnome-shell --no-pager | tail -100.

¿Vale la pena actualizar hoy?

Para la mayoría de los usuarios de GNOME 51, sí. Es un point release conservador que toca áreas donde había fricción real (drag and drop, Nautilus leaks, Orca con GPaste3, frame clock throttling). El riesgo de regresión es bajo porque los cambios son puntuales y bien testeados por el equipo de release.

Donde esperaría:

  • Si usas un setup crítico de producción con apps X11 pesadas (CAD, simuladores, herramientas de edición de video no migradas a Wayland), espera 2-3 semanas a que se asienten los reportes de la comunidad. El rework de drag and drop toca el protocolo, y aunque está bien cubierto por tests, escenarios de borde aparecen en uso real.
  • Si tu distro todavía no ha pushed los paquetes 51.1, no hay urgencia: GNOME 51.0 sigue siendo perfectamente usable, y 51.1 no es un upgrade de seguridad crítico.
  • Si no usas GNOME 51 (todavía en 50, 49, o 48), este post no aplica a tu versión. Espera a tu próximo ciclo de upgrade y los bugfixes de 51.1 llegarán cuando tu distro actualice el stack completo a GNOME 51.

Para mí, en un setup mixto Wayland + Xwayland con Fedora 45, ya actualicé y el drag and drop de PDFs entre Nautilus y un editor gráfico en Xwayland funciona como debe. Era el bug que más me molestaba del stack GNOME del último año, y por fin está resuelto.

Conclusión

GNOME 51.1 no va a aparecer en titulares de tecnología ni va a cambiar cómo trabajas con Linux. Es un point release que cumple su función: arreglar lo que se rompió entre 50 y 51, y dejar el terreno listo para que el próximo batch de features en 51.2 parta de una base estable. El rework de drag and drop Wayland ↔ Xwayland en Mutter es el cambio más visible, y para cualquiera con un setup mixto es motivo suficiente para actualizar. Orca con GPaste3, Nautilus sin leaks, y el throttle del frame clock son bonus que se notan en el día a día.

Si tienes Fedora 45 o Ubuntu 26.10, el upgrade ya está en los mirrors estables. Si no, toca esperar unos días. Y si te encuentras un bug nuevo, el issue tracker de GNOME sigue siendo el mejor lugar para reportarlo con contexto reproducible.

Preguntas frecuentes

¿Cómo verifico que el drag and drop Wayland a Xwayland está usando el rework de Mutter 51.1?

Abre una terminal y corre journalctl -f -u gnome-shell mientras arrastras un archivo desde una app Wayland a una app Xwayland. Si ves líneas wl_data_device enter/motion/drop con source terminando en xwayland, el bridge está activo. Mutter 51.0 también las emitía, pero sin el soporte de MIME text/uri-list que sí está en 51.1.

¿GNOME 51.1 rompe alguna extensión de terceros?

Las extensiones declaradas como compatibles con GNOME 51 siguen funcionando. El cambio que más impacta es el soporte de gnome-autoar para extraer extensions, que facilita la instalación desde ZIPs en GNOME Extensions. Si una extension reportó estado de soporte para 51, no necesita cambios.

¿Vale la pena actualizar desde GNOME 50.x directamente a 51.1?

No. GNOME 50 a 51 es un upgrade mayor que requiere tu distro lo incluya en su próximo ciclo. Este post asume que ya estás en GNOME 51.0 y quieres pasar a 51.1. Si todavía estás en 50, mejor espera al upgrade mayor de tu distro, que vendrá con la nueva serie y todos sus fix.

¿Qué pasa con los drivers NVIDIA propietarios?

Funcionan igual que en 51.0. El rework del cursor fallback a Xcursor puede exponer un bug menor con drivers < 550 donde el cursor desaparece aleatoriamente. El workaround es forzar el cursor nativo de GNOME vía gsettings. NVIDIA 550+ no tiene este problema.

¿Orca 51.1 necesita algo especial para usar GPaste3?

No, GPaste3 ya debe estar corriendo en tu sesión. Si no lo está, instálalo (sudo dnf install gpaste o sudo apt install gpaste). El bridge con Orca se inicializa automáticamente al iniciar la sesión GNOME. Si no funciona, revisa con dbus-monitor --session "interface='org.gnome.GPaste3.*'" que las señales D-Bus están activas.

Lee también

Alfonso Moreno | Sysadmin Senior

Soy Alfonso, sysadmin senior con RHCE y más de 10 años administrando sistemas Linux para empresas y proyectos personales. Me especializo en infraestructura, redes, virtualización, monitoring, automation y self-hosting. Sobre SoyLinux.com SoyLinux.com es un blog técnico en español sobre Linux, software libre y self-hosting. Lo mantengo en mi tiempo libre. Áreas de expertise - Linux server administration: RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu - Network services: Postfix, BIND, Samba, NFS, Squid - Virtualización y containers: KVM, Proxmox, Docker, Podman - Monitoring: Prometheus, Grafana, Zabbix - Automation: Ansible, Bash scripting - Self-hosting: Vaultwarden, Nextcloud, Jellyfin, Immich, Homelab Contacto - Email: [email protected]

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *