Phoenix - un servidor X moderno reescrito desde cero en Zig

• Phoenix es un nuevo servidor X escrito desde cero en el lenguaje Zig, sin bifurcar Xorg, y busca ser una alternativa moderna
• Por ahora puede ejecutar de forma anidada dentro de un servidor X existente aplicaciones simples que usan gráficos GLX, EGL y Vulkan; todavía no admite ejecución independiente
• Para mantener la simplicidad, solo soporta aplicaciones escritas en los últimos 20 años y hardware de los últimos 15 años, y funciona sin una interfaz de controladores del servidor
• Refuerza la seguridad con análisis automático de mensajes del protocolo, y restringe el acceso entre aplicaciones mediante una estructura de aislamiento basada en solicitudes de permisos
• Soporta tecnologías modernas como HDR, VRR, múltiples monitores y compositor integrado, y también planea compatibilidad con Wayland y extensiones del protocolo X11

---

Resumen de Phoenix

• Phoenix es un servidor X moderno para reemplazar al servidor Xorg, una implementación completamente reescrita desde cero en Zig
  • No es un fork de Xorg y apunta a una arquitectura más simple y segura
• Actualmente todavía no está listo para un uso completo y solo soporta ejecución anidada (nested mode) dentro de un servidor X existente
  • Puede realizar renderizado acelerado por hardware basado en GLX, EGL y Vulkan

Objetivos

Simplicidad

• Busca ser un servidor más simple que Xorg, por lo que solo soporta parte del protocolo X11
  • Incluye únicamente las funciones necesarias para aplicaciones escritas en los últimos 20 años
• Está dirigido solo a hardware de los últimos 15 años compatible con Linux DRM y Mesa GBM
• No usa una interfaz de controladores del servidor separada como Xorg
  • Tiene una estructura similar a la de un compositor Wayland

Seguridad

• Garantiza seguridad mediante el análisis automático de mensajes del protocolo
  • Con la opción de compilación ReleaseSafe de Zig, detecta automáticamente operaciones ilegales como desbordes de índices de arreglos
• De forma predeterminada, las aplicaciones se ejecutan aisladas entre sí
  • La interacción con otras apps solo es posible mediante una solicitud de permisos por GUI o autorización previa
  • Ejemplo: una app de grabación de pantalla solo puede grabar la ventana especificada
• Cuando el acceso está restringido, el cliente recibe datos ficticios en lugar de un error
• Los atajos globales funcionan cuando incluyen teclas modificadoras (ctrl, shift, etc.)
  • Usar atajos globales sin teclas modificadoras requiere permisos explícitos
• Mediante opciones, puede cambiarse al mismo comportamiento que Xorg

Soporte para tecnologías modernas

• Soporta tecnologías de pantalla modernas como múltiples monitores, distintas tasas de refresco, VRR y HDR
• En lugar de un único framebuffer, procesa cada pantalla de forma independiente

Mejoras en el procesamiento gráfico

• Ofrece renderizado sin tearing por defecto y un compositor integrado
  • Si se ejecuta un compositor externo (como picom), se desactiva automáticamente
  • Si una app a pantalla completa desactiva vsync, se ajusta en función de esa app
• Busca reducir la latencia de vsync y del compositor

Nuevos estándares

• Define y documenta una propiedad DPI por monitor (randr property)
  • Las aplicaciones pueden escalar el contenido según el DPI de cada monitor

Extensiones del protocolo X11

• Si hacen falta nuevas funciones como HDR, se planean extensiones del protocolo X11

Compatibilidad con Wayland

• Considera la posibilidad de que algunas apps sean exclusivas de Wayland
  • Phoenix podría soportar Wayland directamente o ejecutarlas mediante un puente Wayland–X11 (por ejemplo, 12to11)

Servidor de pantalla anidado

• Permite ejecución anidada acelerada por hardware dentro de X11 o Wayland
  • Es útil para depurar Phoenix y probar gestores de ventanas y compositores
  • En entornos Wayland, puede usarse como servidor alternativo a Xwayland

No objetivos (Non-goals)

• Reemplazar completamente al servidor Xorg no es un objetivo
  • Xorg seguirá manteniendo más funciones de X11 y soporte para hardware antiguo
• No soporta múltiples pantallas X11 (solo múltiples monitores)
• Las llamadas a GrabServer no tienen efecto
• Los clientes/servidores con intercambio de endianess se reconsiderarán si es necesario
• No hay soporte para GLX indirecto (renderizado remoto)
  • Su complejidad es alta y el streaming remoto es más eficiente
  • Si hace falta, el renderizado remoto podría hacerse mediante un proxy GLX

Diferencias con el protocolo X11

• No implementa parte del protocolo central de X11, incluidas funciones relacionadas con fuentes
• La codificación de cadenas usa UTF-8 por defecto
  • Sin embargo, hay excepciones cuando el protocolo especifica ISO Latin-1

Instalación y compilación

• Comandos de instalación:

  zig build -Doptimize=ReleaseSafe
  sudo zig build install -p /usr/local -Doptimize=ReleaseSafe
  

• Para desinstalarlo, hay que borrar manualmente /usr/local/bin/phoenix
• Compilación para desarrollo:

  zig build
  

  • Binario resultante: ./zig-out/bin/phoenix
  • También se puede ejecutar y compilar al mismo tiempo: zig build run

Generación de documentación del protocolo X11

• Comando: zig build -Dgenerate-docs=true
  • Resultado: se generan archivos .txt dentro de ./zig-out/protocol/
  • Es documentación generada automáticamente con estilo de documentación oficial y una función todavía en desarrollo

Dependencias

• Zig 0.14.1
• x11 (xcb) — para modo anidado en X11 (-Dbackends=x11)
• wayland (wayland-client, wayland-egl) — para modo anidado en Wayland (-Dbackends=wayland, actualmente no soportado)
• drm (libdrm, gbm) — para ejecución independiente (-Dbackends=drm, actualmente no soportado)
• OpenGL (libglvnd) — proporciona gl y egl

[GN⁺]

Comentarios en Hacker News

• Es interesante el enfoque de reestructurar el servidor X al estilo Wayland
  Integra por defecto el servidor de pantalla y el compositor, aísla las apps de forma predeterminada, elimina las funciones remotas de GLX y descarta sin miedo protocolos obsoletos; eso resulta llamativo
  No sé quién necesitaría esto, pero la decisión en sí parece bastante razonable

  • Para quienes de verdad necesitan X11, parece una mejor opción que XLibre
  • No lo he probado directamente, pero si quitó funciones existentes, al final parece que quedaría en una situación similar a Wayland
    Entonces no entiendo cuál sería la diferencia. Quizá mi análisis fue incompleto
  • Si esto hubiera salido antes, creo que mucha gente lo habría preferido en vez de Wayland
    Además, si también ejecuta apps de Wayland, de hecho podría atraer a todavía más usuarios

• El nombre Phoenix se usa demasiado
  También está Phoenix en el framework de Elixir, y recuerdo haberlo visto varias veces en otros proyectos
  Es un nombre tan común como "Apollo", así que creo que al crear un proyecto nuevo primero hay que buscar

  • Phoenix del ecosistema de Elixir de hecho es de los menos confusos
    Ahí hay muchos nombres distintivos como bandit, cowboy, thousand island, ranch, mint y finch
    También son comunes los nombres duplicados como ExThing, ThingEx y Thingx, así que cuesta saber cuál es el estándar
  • Desde hace mucho se ha usado Phoenix como símbolo de un proyecto que renace de las cenizas
    Recuerdo que en los años 80 también se nombraba software nuevo de esa manera
  • Firefox también intentó usar el nombre Phoenix y terminó demandado por problemas de marca registrada
    En wxPython también existe un proyecto Phoenix. Suena bien, pero es un nombre demasiado común

• Este proyecto está realmente genial
  Me gusta Wayland, pero los protocolos de portal y el mecanismo de extensiones todavía me dejan insatisfecho
  En productividad hay aspectos donde se queda corto frente a Windows o macOS
  Una reescritura de X11 con seguridad incorporada suena como un enfoque prometedor

  • Llevo tiempo pensando que sería mejor hacer una versión depurada de X en lugar de Wayland
    Parece un proyecto útil, y ojalá avance
  • Dijiste que Wayland se queda corto en productividad, y me da curiosidad saber qué le falta en concreto
  • Yo más bien creo que Windows y macOS ni siquiera manejan bien las ventanas
    A principios de los 2000 incluso instalarlos era difícil, y para un usuario común hacerlo por su cuenta era casi imposible
    Las distribuciones de Linux eran mucho más fáciles de instalar, y si Windows se volvía lento esa era la razón por la que uno terminaba comprando otra PC
  • Yo, al contrario, no he sentido falta de productividad en Wayland
    En el trabajo también uso GNOME + Wayland sin problemas

• Da gusto ver un proyecto de preservación de X de este tipo
  Prefiero Wayland, pero sigo pensando que todavía hay áreas donde X hace falta
  Un nuevo equipo de desarrollo debería repartir la carga

  • Pero creo que este tipo de decisiones provoca fragmentación
    X11 ya debería enterrarse por completo y habría que concentrarse en un solo servidor de pantalla

• No sé qué tan bien vaya a funcionar este proyecto,
  pero me parece bueno que haya más proyectos competidores frente a la tendencia a la unificación centrada en las empresas (por ejemplo, Wayland, GNOME y los desarrolladores pagados de KDE)
  También me pregunto cuánto financiamiento haría falta para modernizar Xorg
  Wayland apareció en 2008, pero incluso después de casi 20 años no ha logrado cubrir todas las necesidades de los usuarios
  Al intentar ajustarse a una especificación estrecha de lo que quieren las empresas, sus límites son evidentes

• Los desarrolladores de aplicaciones pueden especificar el modo de lanzamiento en el script de compilación con algo como zig build --release
  El usuario también puede pasar --release directamente
  Parece que el autor de Phoenix eligió oficialmente el modo ReleaseSafe para los lanzamientos
  Por cierto, Phoenix también es el nombre de mi ciudad natal

• gpu-screen-recorder, del mismo autor, es el mejor grabador de pantalla que he usado en Wayland
  Incluso grabar en 4K 60fps funcionó de inmediato sin tener que configurar nada

• Me pregunto si funcionan apps X11 antiguas como xterm, emacs, xfig y ghostview

  • La mayoría de los programas viejos de X11 dependen de la API de dibujo de X11, así que probablemente no funcionen bien, aunque la implementación en sí es simple

• Dice que el soporte mult pantalla no es un objetivo,
  así que me pregunto si entonces no se podría usar con administradores de ventanas que soportan escritorios virtuales (como i3)

  • En X11, "screen" tiene un significado específico, así que aunque solo se soporte una sola screen
    no hay problema para usar varios monitores o escritorios virtuales
  • La estructura está hecha de forma que funciones de multimonitor continuo como Xinerama se puedan agregar fácilmente después

• Es interesante que, a diferencia de Xorg, no use especificaciones de protocolo XML para generar código