Christian Schaller, quien lidera el grupo de desarrollo de sistemas de escritorio en Red Hat y Fedora Desktop Team, en , relacionados con los componentes de escritorio en Fedora 31, mencionó la intención de Red Hat de cesar el desarrollo activo de las funcionalidades del servidor X.Org y limitarse al mantenimiento de la base de código existente y la corrección de errores.
Actualmente, Red Hat realiza una contribución clave al desarrollo del servidor X.Org y asume su mantenimiento, por lo que, en caso de retirarse del desarrollo, es poco probable que se continúen formando lanzamientos significativos del servidor X.Org. Sin embargo, a pesar de la interrupción del desarrollo, el mantenimiento de X.Org por parte de Red Hat continuará al menos hasta que finalice el ciclo de vida de la distribución RHEL 8, que se extenderá hasta 2029.
La stagnación en el desarrollo del servidor X.Org ya es evidente; a pesar de que anteriormente se aplicaba un ciclo de lanzamiento de seis meses, la última versión significativa, X.Org Server 1.20, se publicó hace 14 meses, y la preparación para el lanzamiento 1.21 está estancada. La situación podría cambiar si alguna empresa o comunidad asume la continuación del aumento de funcionalidades del servidor X.Org, pero, dado el desplazamiento general de proyectos importantes hacia Wayland, es poco probable que se encuentren interesados.
Red Hat actualmente se centra en mejorar el rendimiento del escritorio basado en Wayland. Se espera que la transición del servidor X.Org a modo de mantenimiento se realice después de resolver la tarea de eliminar por completo la dependencia de los componentes de X.Org y asegurar que GNOME Shell se inicie sin utilizar XWayland, lo que requiere refactorización o eliminación de las vinculaciones restantes a X.Org. Estas vinculaciones ya están casi eliminadas de GNOME Shell, pero aún permanecen en el demonio GNOME Setting. En GNOME 3.34 o 3.36 se planea deshacerse por completo de las vinculaciones a X.Org y organizar el inicio de XWayland , en caso de que se necesiten componentes para garantizar la compatibilidad con X11.
También se menciona la necesidad de resolver varios Con Wayland, como el trabajo con los controladores propietarios de NVIDIA y la mejora del servidor DDX de XWayland para asegurar un inicio correcto de aplicaciones X en un entorno basado en Wayland. De los trabajos realizados en el marco de la preparación de Fedora 31, se destaca la implementación en XWayland de la capacidad para iniciar aplicaciones X con privilegios de root. Este tipo de inicio es cuestionable desde el punto de vista de la seguridad, pero es necesario para garantizar la compatibilidad con programas X que requieren trabajar con privilegios elevados.
Otra tarea es mejorar el soporte de Wayland en la biblioteca SDL, por ejemplo, para resolver problemas de escalado al ejecutar juegos antiguos que funcionan en bajas resoluciones de pantalla. También se señala la necesidad de mejorar el soporte de Wayland en sistemas con controladores propietarios de NVIDIA; si bien Wayland ya puede funcionar sobre esos controladores, XWayland en tal configuración aún no puede utilizar recursos para la aceleración de gráficos 3D (se planea proporcionar la posibilidad de cargar el controlador x.org de NVIDIA para XWayland).
Además, se ha mencionado la continuación del trabajo para reemplazar PulseAudio y Jack por un servidor multimedia. , que amplía las capacidades de PulseAudio con herramientas para manejar flujos de video y procesamiento de audio con mínimas latencias, teniendo en cuenta las necesidades de sistemas de procesamiento de audio profesional, y también ofrece un modelo de seguridad ampliado para gestionar accesos a nivel de dispositivos individuales y flujos. En el marco del ciclo de desarrollo de Fedora 31, el trabajo se centra en la aplicación de PipeWire para organizar el acceso compartido a la pantalla en entornos basados en Wayland, incluyendo el uso del protocolo. .
En Fedora 31 también se añade la posibilidad de iniciar aplicaciones Qt en una sesión GNOME basada en Wayland utilizando el plugin Qt Wayland en lugar del plugin XCB, que utiliza X11/XWayland.
Fuente: opennet.ru
