Phoenix - servidor X moderno reescrito do zero em Zig

• Phoenix é um novo servidor X escrito do zero na linguagem Zig, sem fazer fork do Xorg, com o objetivo de ser uma alternativa moderna
• Atualmente, ele consegue executar de forma aninhada, dentro de um servidor X existente, aplicações simples que usam gráficos GLX, EGL e Vulkan, mas ainda não oferece suporte a execução independente
• Em nome da simplicidade, suporta apenas aplicações escritas nos últimos 20 anos e hardware dos últimos 15 anos, funcionando sem interface de driver de servidor
• Reforça a segurança com parsing automático de mensagens do protocolo, e o acesso entre aplicações é limitado por uma estrutura de isolamento baseada em solicitação de permissões
• Oferece suporte a tecnologias modernas como HDR, VRR, múltiplos monitores e compositor embutido, e também planeja compatibilidade com Wayland e extensões do protocolo X11

---

Visão geral do Phoenix

• Phoenix é um servidor X moderno para substituir o Xorg, uma implementação totalmente reescrita do zero em Zig
  • Não é um fork do Xorg e busca uma arquitetura mais simples e segura
• Ainda não está em estágio de uso completo e, por enquanto, suporta apenas execução aninhada dentro de um servidor X existente (nested mode)
  • Pode realizar renderização com aceleração de hardware baseada em GLX, EGL e Vulkan

Objetivos

Simplicidade

• Um servidor mais simples que o Xorg, com suporte a apenas parte do protocolo X11
  • Inclui somente os recursos necessários para aplicações escritas nos últimos 20 anos
• Voltado apenas para hardware dos últimos 15 anos com suporte a Linux DRM e Mesa GBM
• Não usa uma interface separada de driver de servidor como o Xorg
  • Estrutura semelhante à de um compositor Wayland

Segurança

• Garante segurança com parsing automático das mensagens do protocolo
  • Com a opção de build ReleaseSafe do Zig, operações ilegais como acesso além do índice de arrays são detectadas automaticamente
• Por padrão, as aplicações são executadas de forma isolada entre si
  • A interação com outros apps só é possível por meio de solicitação de permissão via GUI ou concessão prévia de permissão
  • Ex.: um app de gravação de tela só pode gravar a janela especificada
• Quando o acesso é restringido, o cliente recebe dados fictícios em vez de erro
• Atalhos globais funcionam quando incluem teclas modificadoras (ctrl, shift etc.)
  • O uso de atalhos globais sem modificadoras exige permissão explícita
• Também é possível alternar por opção para o mesmo comportamento do Xorg

Suporte a tecnologias modernas

• Suporta tecnologias modernas de display como múltiplos monitores, taxas de atualização diferentes, VRR e HDR
• Em vez de um framebuffer único, cada display é tratado de forma independente

Melhorias no processamento gráfico

• Oferece por padrão renderização sem tearing e compositor embutido
  • Ao executar um compositor externo (como picom), ele é desativado automaticamente
  • Se um app em tela cheia desligar o vsync, o comportamento é ajustado para esse app
• O objetivo é reduzir a latência do vsync e do compositor

Novo padrão

• Define e documenta uma propriedade DPI por monitor (randr property)
  • Isso permite que as aplicações façam escala de conteúdo de acordo com o DPI de cada monitor

Extensões do protocolo X11

• Se necessário para novos recursos como HDR, estão planejadas extensões do protocolo X11

Compatibilidade com Wayland

• Considera que alguns apps podem ser exclusivos de Wayland
  • O Phoenix pode suportar Wayland diretamente ou executar esses apps por meio de uma bridge Wayland–X11 (ex.: 12to11)

Servidor de display aninhado

• Pode ser executado com aceleração de hardware de forma aninhada dentro de X11 ou Wayland
  • Útil para depuração do Phoenix e para testes de gerenciadores de janelas e compositores
  • Também pode ser usado como servidor alternativo ao Xwayland em ambientes Wayland

Não objetivos (Non-goals)

• Substituir completamente o servidor Xorg não é um objetivo
  • O Xorg continuará mantendo mais recursos do X11 e suporte a hardware antigo
• Várias telas X11 não são suportadas (apenas múltiplos monitores)
• Chamadas GrabServer não têm efeito
• Clientes/servidores com endian swap poderão ser reconsiderados se necessário
• Não há suporte a GLX indireto (renderização remota)
  • A complexidade é alta, e streaming remoto é mais eficiente
  • Se necessário, a renderização remota pode ser feita via proxy GLX

Diferenças em relação ao protocolo X11

• Parte do protocolo central do X11 ainda não está implementada, como recursos relacionados a fontes
• A codificação de strings usa UTF-8 por padrão
  • Exceção apenas quando o protocolo especifica ISO Latin-1

Instalação e build

• Comandos de instalação:

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

• Para remover, é necessário apagar manualmente /usr/local/bin/phoenix
• Build para desenvolvimento:

  zig build
  

  • Binário gerado: ./zig-out/bin/phoenix
  • Também é possível executar e compilar ao mesmo tempo com: zig build run

Geração da documentação do protocolo X11

• Comando: zig build -Dgenerate-docs=true
  • Resultado: arquivos .txt gerados em ./zig-out/protocol/
  • É uma documentação gerada automaticamente no estilo da documentação oficial e ainda é um recurso em andamento

Dependências

• Zig 0.14.1
• x11 (xcb) — para modo aninhado em X11 (-Dbackends=x11)
• wayland (wayland-client, wayland-egl) — para modo aninhado em Wayland (-Dbackends=wayland, ainda sem suporte)
• drm (libdrm, gbm) — para execução independente (-Dbackends=drm, ainda sem suporte)
• OpenGL (libglvnd) — fornece gl e egl

[GN⁺]

Comentários no Hacker News

• A abordagem de reestruturar o servidor X em um estilo Wayland é interessante
  É impressionante terem integrado por padrão o servidor de exibição e o compositor, isolado os apps por padrão, removido os recursos remotos do GLX e descartado sem medo protocolos obsoletos
  Não sei quem vai precisar disso, mas a escolha em si parece bastante razoável

  • Para quem realmente precisa usar X11, isso parece uma opção melhor do que o XLibre
  • Não testei pessoalmente, mas se removeram recursos existentes, no fim deve ficar parecido com a situação do Wayland
    Então não sei qual seria a diferença. Talvez minha análise esteja incompleta
  • Se isso tivesse surgido mais cedo, muita gente provavelmente teria preferido isso ao Wayland
    Além disso, se apps Wayland também rodarem, na prática ainda mais usuários poderiam escolher isso

• O nome Phoenix está sendo usado demais
  Também existe o Phoenix do framework Elixir, e lembro de já ter visto esse nome em vários outros projetos
  É um nome comum como “Apollo”, então acho que ao criar um projeto novo o ideal é pesquisar antes

  • O Phoenix do ecossistema Elixir até é menos confuso
    Lá eles têm muitos nomes peculiares como bandit, cowboy, thousand island, ranch, mint e finch
    Também é comum haver nomes duplicados como ExThing, ThingEx e Thingx, o que deixa confuso saber qual é o padrão
  • Há muito tempo o nome Phoenix é usado como símbolo de um projeto renascendo das cinzas
    Lembro de software novo ser batizado assim já nos anos 1980
  • O Firefox também tentou usar o nome Phoenix e acabou sendo processado por questões de marca registrada
    O wxPython também tem um projeto Phoenix. É um nome legal, mas comum demais

• Esse projeto é realmente muito legal
  Gosto do Wayland, mas os protocolos de portal e o mecanismo de extensões ainda deixam a desejar
  Em comparação com Windows ou macOS, ainda faltam coisas em termos de produtividade
  Reescrever o X11 com segurança embutida parece uma abordagem promissora

  • Faz tempo que penso que seria melhor fazer uma versão organizada do X em vez do Wayland
    Parece um projeto útil, e espero que evolua
  • Você disse que o Wayland fica devendo em produtividade; queria saber o que exatamente está faltando
  • Eu acho que Windows ou macOS é que mal conseguem fazer gerenciamento de janelas direito
    No começo dos anos 2000 até instalar era difícil, e para um usuário comum instalar por conta própria era quase impossível
    As distribuições Linux eram muito mais fáceis de instalar, e quando o Windows ficava lento era por isso que as pessoas compravam um PC novo
  • Eu, pelo contrário, não senti falta de produtividade no Wayland
    No trabalho também uso GNOME + Wayland sem problema nenhum

• É bom ver um projeto desse tipo de preservação do X
  Prefiro Wayland, mas ainda acho que existem áreas em que o X continua sendo necessário
  Uma nova equipe de desenvolvimento precisa dividir essa carga

  • Mas acho que esse tipo de escolha causa fragmentação
    O X11 já deveria ser enterrado de vez, e o foco deveria ficar em um único servidor de exibição

• Não sei o quão bem esse projeto vai funcionar, mas,
  diante da tendência de unificação centrada em empresas (por exemplo: Wayland, GNOME e KDE com desenvolvedores pagos),
  acho bom que existam mais projetos concorrentes
  Também fico curioso sobre quanto financiamento seria necessário para modernizar o Xorg
  O Wayland surgiu em 2008, mas mesmo após quase 20 anos ainda não conseguiu atender a todas as necessidades dos usuários
  Fica claro que há limites quando se tenta encaixar tudo em uma especificação estreita desejada por empresas

• Desenvolvedores de aplicações podem especificar o modo de release em scripts de build na forma zig build --release
  O usuário também pode passar --release diretamente
  Parece que o autor do Phoenix escolheu o modo ReleaseSafe como release oficial
  Aliás, Phoenix também é o nome da minha cidade natal

• O gpu-screen-recorder, feito pelo mesmo autor, é o melhor gravador de tela que já usei no Wayland
  Gravação em 4K 60fps funcionou de cara, sem nenhuma configuração especial

• Fico curioso se apps X11 antigos como xterm, emacs, xfig e ghostview funcionam

  • A maioria dos programas X11 antigos provavelmente não vai funcionar direito, porque depende da API de desenho do X11, mas a implementação em si é simples

• O suporte a múltiplas telas está listado como algo fora do escopo,
  então fiquei na dúvida se isso significa que não poderia ser usado com um gerenciador de janelas com desktops virtuais (como i3)

  • Em X11, “screen” tem um significado específico, então mesmo suportando apenas uma única screen
    não há problema para usar múltiplos monitores ou desktops virtuais
  • Recursos de múltiplos monitores contínuos, como o Xinerama, têm uma estrutura que permite adição fácil depois

• É interessante que, diferente do Xorg, ele não use especificações de protocolo em XML para gerar código