Salió YSERVER 1.5, el servidor X11 moderno escrito en Rust que arrancó hace unos meses y que, dado el tamaño de X11, se programó en buena parte con Claude Code. Phoronix publicó el lanzamiento el 9 de septiembre de 2026 y anota que el proyecto sigue sumando aportes de más usuarios.
Esta implementación de X11 hecha desde cero en Rust corre entornos de escritorio y gestores de ventanas reales, entre ellos Cinnamon, MATE, Xfce, Compiz, Openbox, IceWM y Enlightenment. La versión 1.5 trae más correcciones y algunas funciones nuevas.
¿Qué es Reverse PRIME y por qué costó tanto?
La novedad principal es el soporte de Reverse PRIME para equipos con varias GPU, donde la tarjeta principal renderiza las imágenes y después las entrega a la secundaria. Es la configuración típica de un notebook con gráfica dedicada cuyas salidas de video cuelgan del chip integrado, o al revés.
Tras semanas de ida y vuelta, el cambio se integró luego de pruebas exitosas en hardware y de corregir varios errores en el camino. Para que funcionara hubo que agregar plomería en todo el trayecto, desde el mapeo de dispositivos DRM a GPU de Vulkan hasta la exposición de la topología de proveedores de RandR.
¿Por qué CS2 corría a la mitad de los cuadros?
YSERVER 1.5 también destraba el tope que sufrían los clientes con vsync apagado, con ejecución diferida y manejo de supersesión sobre el mismo destino. Eso corrige una regresión frente al servidor X.Org original en juegos que corren a pantalla completa sin sincronía vertical, como Counter-Strike 2.
| Servidor | Cuadros por segundo en CS2 |
|---|---|
| YSERVER antes del cambio | 180 a 200 |
| X.Org Server | cerca de 400 |
La explicación está en la solicitud de integración correspondiente.
"Un cliente con vsync apagado queda topado en imágenes del swapchain por refresco. CS2 midió 180 a 200 fps en yserver contra cerca de 400 en Xorg, y la causa es la compuerta de ritmo de vblank del 27 de julio de 2026, que retiene la liberación del búfer (IdleNotify o el syncobj de liberación) hasta el siguiente MSC, así que un swapchain de 3 o 4 imágenes solo puede reciclar 3 o 4 búferes por vblank a 60 Hz."
La captura original mostraba exactamente 3 o 4 copias por intervalo de composición, enganchadas en fase, mientras el tiempo real de cuadro del juego era de unos 2,7 milisegundos. En la práctica el problema es específico de la capa WSI de NVIDIA, porque la de Mesa activa PresentOptionAsync sin condiciones cuando el vsync está apagado y esquiva la compuerta, mientras la de NVIDIA envía presentaciones sincronizadas y depende de un mecanismo de descarte al estilo de Xorg que yserver no había implementado. La diferencia que queda contra los 400 fps de Xorg pertenece al camino de volteo de búferes y quedó fuera del alcance de este cambio.
¿Qué más trae la versión?
- Consultas de tasa MSC de OML de Mesa, para corregir errores que aparecían en algunas aplicaciones Flatpak que usan ANGLE
- Aplicación de la configuración de perfil de aceleración del escritorio
- Objetos de sincronización DRI3 1.4 servidos a través de DRM
- Soporte de bordes de ventana dibujados por el servidor
- Correcciones varias
El detalle completo de YSERVER 1.5 está en la publicación del lanzamiento en GitHub.
