Red Hat tiene la intención de detener el desarrollo del servidor X.Org

Christian Schaller, jefe del equipo de desarrollo de escritorio de Red Hat y del equipo de escritorio de Fedora, revisión de planes, con respecto a los componentes de escritorio en Fedora 31, mencionó la intención de Red Hat de dejar de desarrollar activamente la funcionalidad del servidor X.Org y limitarse a mantener el código base existente y corregir errores.

Actualmente, Red Hat es un contribuyente clave para el desarrollo del servidor X.Org y lo mantiene, por lo que es poco probable que continúen las versiones significativas del servidor X.Org en caso de un descarrilamiento. Al mismo tiempo, a pesar de la finalización del desarrollo, el mantenimiento de X.Org por parte de Red Hat continuará al menos hasta el final del ciclo de vida de la distribución RHEL 8, que durará hasta 2029.

El desarrollo de X.Org Server ya se está estancando: a pesar del ciclo de lanzamiento anterior de seis meses, la última versión importante de X.Org Server 1.20 se publicó hace 14 meses y la preparación de la versión 1.21 se está estancando. La situación puede cambiar si alguna empresa o comunidad se hace cargo del crecimiento continuo de la funcionalidad del servidor X.Org, pero, dado el cambio generalizado de proyectos significativos hacia Wayland, es poco probable que haya quienes lo deseen.

El enfoque actual de Red Hat es mejorar la experiencia de escritorio basada en Wayland. Se espera la transición del servidor X.Org al modo de mantenimiento después de la tarea de eliminar por completo la dependencia de los componentes X.Org y hacer que GNOME Shell se ejecute sin usar XWayland, lo que requiere refactorizar o eliminar los enlaces restantes a X.org. Estos enlaces casi han desaparecido del GNOME Shell, pero aún permanecen en el daemon de configuración de GNOME. En GNOME 3.34 o 3.36, está previsto eliminar por completo los enlaces a X.Org y organizar el lanzamiento de XWayland. dinamicamente, cuando se necesitan componentes para garantizar la compatibilidad con X11.

También menciona la necesidad de resolver una serie de problemas restantes con Wayland, como trabajar con controladores patentados de NVIDIA y ajustar el servidor XWayland DDX para ejecutar bien las aplicaciones X en un entorno basado en Wayland. Del trabajo realizado como parte de la preparación de Fedora 31, se destaca la implementación en XWayland de la capacidad de ejecutar aplicaciones X con privilegios de root. Ejecutarlo así es cuestionable desde el punto de vista de la seguridad, pero necesario para garantizar la compatibilidad con los programas X que necesitan ejecutarse con privilegios elevados.

Otro objetivo es mejorar la compatibilidad con Wayland en SDL, por ejemplo, para resolver problemas de escalado cuando se ejecutan juegos antiguos con resoluciones de pantalla bajas. También se observa la necesidad de mejorar la compatibilidad con Wayland en sistemas con controladores patentados de NVIDIA: si Wayland ha podido trabajar sobre dichos controladores durante mucho tiempo, entonces XWayland en esta configuración aún no puede usar herramientas para la aceleración de hardware de gráficos 3D. (está planeado proporcionar la capacidad de cargar el controlador x.org NVIDIA para Xwayland).

Además, continúa el trabajo para reemplazar PulseAudio y Jack con un servidor multimedia. PipeWire, que amplía las capacidades de PulseAudio para la transmisión de video de baja latencia y el procesamiento de audio para satisfacer las necesidades de los sistemas de procesamiento de audio profesionales, y también ofrece un modelo de seguridad ampliado para controlar el acceso a nivel de dispositivos y transmisiones individuales. Como parte del ciclo de desarrollo de Fedora 31, el trabajo se centra en el uso de PipeWire para organizar el uso compartido de pantalla en entornos basados ​​en Wayland, incluido el uso del protocolo Miracast.

Red Hat tiene la intención de detener el desarrollo del servidor X.Org

En Fedora 31 también planeado agregue la capacidad de ejecutar aplicaciones Qt en una sesión de GNOME basada en Wayland usando el complemento Qt Wayland en lugar del complemento XCB usando X11/XWayland.

Fuente: opennet.ru

Añadir un comentario