Lançamentos do X.Org: presente e futuro

A Fundação X.Org lançou o xorg-server 1.7 no dia 1º de outubro, preparando o terreno para o lançamento iminente do X11R7.5. Os usuários podem esperar por melhorias na configuração e nas transformações da tela e também nos dispositivos de entrada, incluindo o aguardadíssimo código do MPX, ou X multiponteiro, que oferece suporte a múltiplos pontos independentes de foco de teclado e ponteiros de mouse. E a equipe de desenvolvimento também está traçando planos para adotar um novo processo de lançamentos: a ideia é adotar uma agenda previsível de lançamentos e aprimorar a fase de testes.

As novidades do 1.7 e do 7.5

As alterações em nível de sistema nesta nova versão incluem diversas tecnologias novas para lidar com monitores, como o suporte ao E-EDID e a atualização do XRandR (que se encarrega de redimensionar, girar e refletir a tela). Uma melhoria que havia sido proposta para a arquitetura de aceleração EXA, o “Shatter”, ficou para uma próxima versão.

O E-EDID é uma revisão do formato EDID, e através dele os monitores fornecem uma lista de recursos às placas de vídeos. O E-EDID tem suporte a strings maiores do que as do EDID, permite a localização dessas strings e ainda adiciona campos para a alteração da taxa de proporção e inclui novas fórmulas para “timing” e frequências. Um dia o E-EDID vai ser substituído por um formato mais novo chamado DisplayID, mas ele é particularmente importante para os usuários de eletrônicos domésticos, graças ao seu uso em dispositivos HDMI.

O XRandR 1.3 inclui dois novos recursos: panorâmicas e transformações projetoras. As transformações projetoras permitem transformações mais generalizadas do buffer de imagens do que a rotação e a reflexão, que já eram suportadas. Elas vão permitir que as transformações apliquem correções para distorções diversas, e também o escalonamento do buffer de imagens. Se o desktop exibido for menor do que o tamanho da tela virtual, a panorâmica permitirá que a tela siga o cursor automaticamente.

O projeto que foi adiado, o Shatter, foi um dos projetos do X.Org para o Google Summer of Code, e quando integrado, permitirá que telas sejam divididas entre múltiplos framebuffers.

Os dispositivos de entrada também passam por mudanças nesta versão, principalmente devido ao MPX. Como o nome indica, o MPX permite o uso simultâneo de múltiplos dispositivos de entrada. Isso não quer dizer simplesmente que dois mouses e dois teclados podem ser conectados fisicamente; o X já permite isso há um bom tempo. Mas sem o MPX, os vários mouses conectados controlam o mesmo ponteiro, e os teclados direcionam a entrada para um mesmo local. Com o MPX, podem haver vários cursores separados, com foco independente. Alguns aplicativos e kits de ferramentas do X vão precisar ser modificados para que funcionem com o MPX, já que foram programados presumindo que haveria apenas um teclado e um apontador.

O MPX é parte do XInput2, uma revisão maior do sistema de entrada do X. O XInput2 continua de onde a API anterior (XInput) parou, e inclui outros recursos como as Propriedades de Dispositivos de Entrada, um mecanismo através do qual propriedades genéricas podem ser anexadas a dispositivos de entrada para que relatem características especiais ao servidor X e a seus aplicativos. Essas propriedades podem incluir limites de tempo para os botões do mouse, aceleração do ponteiro ou até mesmo nomes lógicos (como por exemplo, para distinguir os vários mouses conectados).

Outras atualizações em subsistemas específicos incluem alterações para arbitragem VGA, Mesa e SELinux, melhorias no servidor XQuartz desenvolvido para o Mac OS X e o descarte de vários módulos e extensões obsoletos e sem manutenção.

O processo para o 1.8

Em um email enviado à lista de discussão xorg-devel no dia 26 de setembro, Peter Hutterer propôs uma reformulação no processo de lançamento do X.Org. Ele apontou três problemas no processo atual: a agenda é imprevisível; há desenvolvimento demais na árvore principal do git, o que muitas vezes faz com que ela fique inutilizável; e o ciclo de testes é muito pequeno e já ocorre nos momentos finais do processo de lançamento. Ele observou que os três problemas estão intimamente relacionados, e propôs a adoção de uma agenda de lançamentos previsível, com janelas separadas para a fusão de recursos (“merging”), a correção de bugs e os testes finais.

O processo proposto começa com a criação de árvores separadas para recursos novos, em vez de desenvolvê-los como conjuntos de patches que podem tumultuar a árvore principal. Em cada ciclo de lançamento, o projeto usaria uma janela de tempo de três meses para a fusão, integrando as árvores de recursos à árvore principal, para então entrar em um período de dois meses de correções de bugs e, por fim, congelar a árvore principal por um mês, quando um gerente de lançamento assume o controle e só permite a fusão de correções cruciais. O resultado, defende Hutterer, seria um ciclo de lançamento previsível de seis meses, e um ambiente de trabalho muito mais fácil para os encarregados dos testes.

Keith Packard questionou se 3:2:1 seria a melhor proporção para a fusão de recursos, a correção de bugs e o congelamento, observado especificamente que a janela de tempo para a fusão de recursos é consideravelmente maior do que a usada pela equipe do kernel do Linux. Hutterer replicou, dizendo que achava que o valor era um bom começo, especialmente porque o processo todo seria novo, mas acrescentou que todas as facetas do processo deveriam ser reavaliadas após o ciclo da versão 1.8, incluindo a possibilidade de reduzir o período de fusão.

Os efeitos da proposta sobre a fase de testes foram particularmente populares com os outros desenvolvedores na lista durante a discussão que se seguiu. Muitos compararam as diferenças entre o X.Org e o kernel do Linux, começando pela relativa escassez de pessoas testando o X.Org. O consenso na discussão foi de que a culpa era da instabilidade da árvore principal do git e da falta de documentação para guiar aqueles dispostos a testar o código; uma revisão no processo de lançamento, com uma árvore principal estável e árvores individuais para recursos, contribuiria bastante para a criação de uma comunidade de beta-testers ativos do X.Org.

Hutterer fez sua proposta na lista porque não poderia comparecer à Conferência de Desenvolvedores do X, a XDC 2009, ocorrida de 28 a 30 de setembro em Portland, EUA. Os participantes da XDC discutiram a proposta, e Daniel Stone postou as decisões tomadas na xorg-devel. O grupo pretende adotar o modelo básico proposto no ciclo de lançamento do xorg-server 1.8/X11R7.6, acrescentando a escolha de gerentes de lançamento para cada ciclo e solicitando aos desenvolvedores que adotem árvores para cada subsistema, da mesma forma que os desenvolvedores do kernel fazem.

O email de Stone gerou controvérsia, graças à sugestão de que se o novo processo fosse bem sucedido no ciclo da versão 1.8/7.6, a próxima etapa seria fundir os drivers gráficos à árvore principal do xorg-server para o ciclo da versão 1.10/7.7. Os argumentos contra a fusão dos drivers à base de código principal do xorg-server incluem incompatibilidades de licenças, mas um número maior de desenvolvedores vê na simplicidade de manter os drivers na mesma base de código do servidor uma recompensa a longo prazo. Ainda assim, essa alteração no gerenciamento do código fonte ainda é apenas uma proposta, e voltada para daqui a dois ciclos de versões.

O principal objetivo do novo processo de lançamento proposto é o de tornar a base de código do X.Org mais estável, mais previsível e, consequentemente, mais fácil de testar. Como muitos destacaram na lista xorg-devel, o xorg-server é usado em tantos sistemas quanto o kernel do Linux, mas conta com apenas uma pequena parcela dos “pilotos de testes” ativos que ajudam a tornar o kernel tão robusto. O X.Org continua criando melhorias e aperfeiçoamentos a cada nova versão, e a turma pessimista que há dez anos dizia que o X deveria ser abandonado já não existe. Esperamos que o X11R7.6 e o xorg-server 1.8 cheguem dentro dos seis meses previstos, e que exibam os frutos de um processo de testes mais longo e determinado.