Conhecendo o Servidor X
From CInLUG
Conteúdo |
Introdução
Neste artigo veremos um dos componentes mais legais de um sistema GNU/Linux (e {Free|Open|Net}BSD, Solaris e outros *nixes; são tantos que doravante usaremos apenas o termo "Linux"): o Servidor X.
O Servidor X não se trata do centro de TI da Mansão do Professor Xavier (esse é o Cerebro, recentemente Cerebra, mas aí é outra história...), e sim do resposável pela manipulação das primitivas gráficas como pontos, linhas e retângulos, e interface com hardware gráfico e entrada de dados (e.g.: mouse, teclado). Basicamente, tudo que você vê no modo gráfico do Linux, partiu de uma solicitação de uma aplicação ou biblioteca para o servidor X, e todas as informações recebidas por uma aplicação vieram do servidor.
Filosofia Unix
Antes de continuar vamos dar uma olhada na estrutura típica de um sistema Linux. O diagrama abaixo mostra uma representação em "camadas".
Cada camada recebe solicitações da camada superior e faz solicitações à camada inferior. Embora camadas superiores possam "pular" camadas vizinhas e fazer suas solicitações para camadas ainda mais abaixo, as camadas inferiores não tem consciência de quem está em cima. E em cima de tudo está o usuário que ao interagir com a interface gráfica, não precisa saber se estamos rodando um kernel do Linux, FreeBSD, OpenSolaris, HURD ou Minix3, ou o que quer que inventem amanhã. Ou seja, podemos trocar qualquer componente por outro compatível com os padrões utilizados e que forneça os mesmos serviços, sem prejuízo para o sistema. Lembrando que o padrão seguido pelos *nixes é o POSIX, que estabelece compatibilidade em nível de código fonte, e recompilações seriam necessárias, possivelmente em outras camadas além da que estivesse sendo substituída.
A filosofia Unix diz "faça uma coisa e faça muito bem", e "junte vários pequenos programas para resolver grandes problemas", o que eu gosto de chamar de "Lego Way of Life", pois é exatamente isso que esse estilo de arquitetura modular ajuda a promover. Outra vantagem é poder sair mais facilmente de uma situação desagradável ou restritiva. Como foi o caso do servidor XFree86, que devido à uma mudança no licenciamento e outros problemas (não sei ao certo, talvez alguém querendo se proclamar imperador divino, ou algo assim), fizeram com que a maioria dos desenvolvedores saíssem do projeto com o código anterior a mudança da licença e criassem o X.Org, gerido pela X.Org Foundation. Hoje em dia X.Org avança muito mais rápido que o XFree86 e é o padrão da maioria das distribuições, equanto isso o XFree86 agoniza lentamente. A substituição não foi tecnicamente problemática pois os clientes continuavam fazendo suas solicitações via o protocolo X11.
X11
O quê estivemos chamando de Servidor X é formalmente conhecido como X Window System, ou simplesmente X para os amigos. O protocolo X foi criado em 1984 no MIT, atualmente estamos na versão 11, daí também chamarmos de X11, e sua implementação mais utilizada é o X.Org. Bem, no parágrafo anterior eu falei protocolo, pois é isso mesmo, as aplicações e bibliotecas gráficas se comunicam com o Servidor X através de um protocolo, e se você pensou que por isso podemos rodar o X numa máquina diferente usando o velho paradigma cliente servidor, então acertou. Contudo, a idéia de quem é o cliente e quem é o servidor aparenta estar invertida neste caso. Se interajo com uma aplicação rodando remotamente, vou supor que sou o cliente e a outra máquina o servidor. Mas no caso do X, minha máquina será o servidor para a aplicação remota, pois esta enviará os pedidos (desenhe uma janela, um ícone, etc) para o servidor X rodando na minha máquina, que por sua vez exibirá na minha tela as solicitações da aplicação cliente X, e enviará para mesma a movimentação do mouse e entradas do teclado relevantes. A imagem a seguir ajuda a visualizar o conceito:
A arquitetura do X11 nos uma enorme flexibilidade. Veja algumas das coisas que podemos fazer:
- X11 via SSH
Usando o cliente ssh com o parâmetro -X habilitamos o chamado "X11 forwarding", de forma que quando executarmos uma aplicação gráfica (e.g.: xeyes) ela será processada na máquina remota, contudo todas as solicitações gráficas chegarão à nossa máquina pela conexão criptografada.
$ ssh fulano@servidor -X
- Multihead
O Incrível Computador de Duas Cabeças! Freakshow total!
Não mais falarei, apenas vejam o diagrama:
Duas cabeças não são o limite, tudo que é necessário são monitores e placas de vídeo na quantidade certa. Esse recurso é conhecido como Xinerama.
- Múltiplos Servidores X
Podemos rodar mais de um servidor X na mesma máquina, o que é facilmente observável nas distribuições mais modernas, que costumam ter uma opção "Logar como outro usuário" (sem deslogar o anterior. Quando outro usuário abre uma sessão, está também abrindo outro servidor X, ao qual é atribuído um número único para que o sistema saiba para onde enviar as solicitações gráficas. Se estiver num terminal, basta definir a variável de ambiente DISPLAY com o valor numérico associado ao servidor X no momento de sua criação.
Também podemos fazer um CPU servir múltiplos terminais: http://pt.wikibooks.org/wiki/Multiterminal_com_Xephyr
Podemos ainda ter servidores X dentro de outro servidor X, é o que se chama servidor aninhado, e será isso que nos ajudará nas explorações a seguir. O servidor aninhado que usaremos será o Xephyr.
Compare o diagrama e o screenshot a seguir.
A aplicação Mahjongg é cliente para o servidor Xephyr, que por sua vez é cliente para o servidor X.Org que é responsável pelos gráficos do desktop onde roda a janela do Xephyr. Veremos
Gerenciador de Janelas x Ambiente Desktop
Até agora estivemos tratando o ambiente gráfico como algo único sobre o servidor X, mas na verdade esta "camada" ainda se divide em duas: o Gerenciador de Janelas e o Ambiente Desktop. O primeiro é mais fácil de definir, o segundo é mais abstrato.
O paradigma gráficos que estamos acostumados é chamado de WIMP - Window, Icon, Menu, Pointing device (Janela, Ícone, Menu, Dispositivo de apontador). Bem familiar, não é mesmo? É aquele velho paradigma desenvolvido pela Xerox e copiado por todos. Afinal o que é bom deve ser copiado. ;) No paradigma WIMP, o servidor X cuida apenas do dispositivo apontador (além do hardware de vídeo e teclado), o Gerenciador de Janelas entra com a parte, bem, das Janelas! Quando uma aplicação gráfica é iniciada o gerenciador coloca uma borda na mesma, e cuida de toda lógica de por trás do ato de, por exemplo, "agarrar" a barra de título da janela e arrastá-la para outra posição. O servidor X não entende disso e as aplicações acima não se importam quem vai cuidar disso para elas, ou mesmo se vai haver alguém cuidando. O Gerenciador de Janelas "puro" normalmente não oferece abstração para ícones e menus, pois espera que o Ambiente Desktop os ofereça. Contudo, nada impede que o façam, alguns Gerenciadores de Janelas como Fluxbox e Enlightenment foram criados para serem usados sem necessidade de outros componentes "superiores".
A imagem a seguir mostra uma janela do jogo Mahjongg com o menu de janela aberto. Para ver basta clicar no ícone da aplicação no canto esquerdo superior da janela, mas essa instrução é no Metacity, pode haver outro gerenciador que coloca o menu eu outro lugar, ou nem o disponibiliza. Os botões para minimizar, maximizar e fechar uma janela, no canto superior direito da mesma, também são convenções e existem gerenciadores (e mesmo temas diferentes de um mesmo gerenciador) que mudam tudo de lugar. A opção "No Topo", em destaque na imagem, faz com que a janela em questão fique sempre na frente das outras, mesmo que não esteja ativa. Este é mais um exemplo de funcionalidade especifica do gerenciador de janelas.
Como foi dito antes, o Ambiente Desktop é algo mais abstrato. Consiste de um conjunto de bibliotecas, serviços (daemons) e facilidades, muito bem integrados para provêr uma experiência agradável e consistente para o usuário. O que obiviamente os torna mais pesados que um simples Gerenciador de Janelas, e isto é um dos motivos que fazem os usuários mais hardcore preferirem gerenciadores como o Fluxbox, que de longe já satisfazem as suas necessidades gráficas.
Os três principais Ambientes Desktop do Linux são GNOME, KDE e XFCE. Este último embora tenha menos recursos que os outros dois, os tem em maior quantidade que qualquer gerenciador de janelas "puro", com a vantagem de ser o mais leve, o que acaba fazendo dele uma boa escolha para máquinas mais modestas.
Voltando ao "Lego Way of Life", recentemente a Novell liberou o servidor XGL, que usa a aceleração 3D da placa de vídeo para fazer uns efeitos especiais de encher os olhos e matar de inveja usuários de rWindows (veja isso, isso e isso). (E os efeitos são úteis! Não apenas frescurites e arco-íris.) Foram feitas muitas demonstrações, vídeos foram divulgados, várias pessoas testaram com um LiveCD, e todos perguntavam "mas eu só vi com o GNOME, funciona com o KDE? XFCE? Posso ter meu Flux com o cubo 3D?" A resposta é sim para todos, o XGL é um servidor X que segue o padrão X11, de modo que será transparente para o gerenciador de janelas e ambiente desktop que estiver rodando em seu topo. Embora, se alguma funcionalidade extra for oferecida o gerenciador de janelas deve ser adaptado de acordo.
Também existe o AIGLX ("Accelerated Indirect GL X") da X.Org Foundation, e a cooperação entre os dois projetos parece estar indo muito bem.
Xephyr
A partir de agora faremos algo prático, vamos precisar ter instalado o servidor Xephyr, os gerenciadores de janelas Metacity, Fluxbox e Enlightenment. Se você estiver usando Debian/Ubuntu, basta fazer
$ sudo apt-get install xserver-xephyr fluxbox enlightenment
Se estiver em outra distribuição veja no seu gerenciador de pacotes, os mais aventureiros podem baixar os fontes e... ah, vocês já sabem os procedimentos de rotina. ;P
Os sites são:
- http://www.freedesktop.org/wiki/Software_2fXephyr
- http://fluxbox.sourceforge.net/
- http://www.enlightenment.org/
O Metacity é o gerenciador de janelas padrão do GNOME, e já deve estar a postos. Para ver os efeitos dos nossos testes de forma confortável, recomendo uma disposição de tela como a do primeiro screenshot. Abra um terminal e vamos repetir o que vimos na primeira imagem:
$ Xephyr -ac :2 -screen 640x480 & $ export DISPLAY=:2 $ mahjohngg &
A primeira linha invoca o Xephyr, o parâmetro "-ac" desabilita restrições de controle de acesso (seja lá o que isso signifique), ":2" indica o identificador de display que será usado para endereçar a janela do Xephyr, e "-screen 640x480", por mais surpreendente que pareça, diz o tamanho da janela. Fullscreen também é suportada com o parâmetro "-fullscreen". O Xephyr não tem manpage (pelo menos não no meu sistema), mas tem uma ajuda de linha de comando bem razoável:
$ Xephyr --help
A segunda linha define a variável de ambiente DISPLAY de forma a direcionar todas as operações gráficas das aplicações iniciadas neste terminal para o servidor X associado ao valor :2, que é o valor que atribuímos ao Xephyr. Quando o terminal for fechado o valor será perdido e tudo voltará ao normal. A terceira linha inicia o Mahjohngg em 'background'. Hmmm, vamos invocar mais duas aplicações para animar mais.
$ xcalc & $ xeyes &
Ignore eventuais Warnings pressionando Enter, e vamos ver como ficou:
Tosco, hein? Tudo amontoado. O motivo é que temos um servidor X, temos aplicações gráficas, mas nada de gerenciador de janelas. Isso pode ser remediado da seguinte forma:
$ metacity &
Vejamos novamente como ficou.
Bem melhor agora, embora eu tenha arrumado as janelas para posições mais fotogênicas. Mas chega de frescuras com janelas, vamos matar o Metacity e voltar a bagunça!
$ ps aux | grep metacity setanta 16031 0.2 3.4 15896 7824 ? Ss Jul02 0:53 /usr/bin/metacity --sm-client-id=default0 setanta 28273 0.8 4.1 15332 9296 pts/2 S 02:59 0:02 metacity setanta 28386 0.0 0.3 2888 812 pts/2 R+ 03:03 0:00 grep metacity $ kill -9 28273
Notem que no meu computador apareceram dois processos metacity, o primeiro é o da sessão gráfica em que estou logado. As aplicações no Xephyr ficaram assim (tá, não estão no mesmo lugar do screenshot anterior, porque eu mexi de novo nas posições das janelas antes do assassinato do Metacity... :P):
Com as aplicações ainda abertas usaremos outro gerenciador de janelas. Usaremos o iluminado Enlightenment
$ enlightenment &
Brinque um pouco com as janelas para sentir a diferença. Algumas pessoas preferem usar o GNOME com o Enlightenment em lugar do Metacity e configuram o sistema de acordo. (Mesmo que não vá instalar, não deixe de ver os Screenshots!)
Chega de Enlightenment...
$ kill -9 `pidof enlightenment`
...agora é a vez do Flux:
$ fluxbox &
Brinque mais um pouco com o Fluxbox para ver as diferenças para o Enlightenment e Metacity.
 Sobre o comando anterior, as crases (`) dizem para o shell executar o comando entre elas e copiar e colar seu valor de retorno na linha de comando, kill -9 matará os processos com os pids (process ID) indicados, e pidof retorna o(s) pid(s) de um processo indicado pelo nome. |
xrandr
Agora, a parte ainda mais divertida, iremos alterar o comportamento do Xephyr on-the-fly com a ferramenta xrandr, que envia comandos para um servidor X11 (e também serve para outras coisas).
Alterar o tamanho da janela:
$ xrandr -d :2 -s 320x240+0+0 $ xrandr -d :2 -s 800x600+0+0 $ xrandr -d :2 -s 640x480+0+0
O parâmetro "-d :2" se refere ao display (id do servidor X) sendo alterado, "-s 800x600+0+0", diz respeito às dimensões, o "+0+0" eu não sei o que é, tentei alguns valores e nada acontecia de diferente, a documentação do xrandr não estava das melhores e eu não queria olhar o código só por causa disso. Desculpas, desculpas, desculpas... seus esclarecimentos são bem-vindos!
Espelhar (horizontal e vertical, respectivamente):
$ xrandr -d :2 -x $ xrandr -d :2 -y
xrandr -d :2 -x
Mudar orientação:
$ xrandr -d :2 -o inverted $ xrandr -d :2 -o left $ xrandr -d :2 -o right $ xrandr -d :2 -o normal
xrandr -d :2 -o inverted
xrandr -d :2 -o left
Conclusão
Espero que este artigo tenha sido útil para tirar algumas dúvidas sobre como o sistema gráfico de um sistema GNU/Linux (e outros *nixes) é estruturada, e que a parte prática tenha sido divertida. :D Agradecimentos adiantados para quem encontrar e me avisar de algum erro ou lapso no texto.
| Autor: Marcelo Lira |
