Como é organizada a pilha de gráficos linux?

Alguém pode explicar (espero que com uma foto), como é organizada a pilha de gráficos linux? Eu ouço o tempo todo sobre X / GTK / GNOME / KDE etc., mas realmente não tenho idéia do que eles realmente fazem e como eles interagem entre si e com outras partes da pilha. Como o Unity e o Wayland se encaixam?

O sistema X Window usa uma arquitetura cliente-servidor. O servidor X é executado na máquina que possui a tela (monitores + dispositivos de entrada), enquanto os clientes X podem ser executados em qualquer outra máquina e se conectar ao servidor X usando o protocolo X (não diretamente, mas usando uma biblioteca, como Xlib, ou o mais moderno XCB controlado por eventos, sem bloqueio). O protocolo X foi projetado para ser extensível e possui muitas extensões (consulte xdpyinfo(1)).

O servidor X realiza apenas operações de baixo nível, como criar e destruir janelas, executar operações de desenho (atualmente a maioria dos desenhos é feita no cliente e enviada como uma imagem para o servidor), enviando eventos para as janelas, ... Você pode ver quão pouco um servidor X executa executando X :1 &(use qualquer número ainda não usado por outro servidor X) ou Xephyr :1 &(o Xephyr executa um servidor X incorporado no seu servidor X atual) e depois execute xterm -display :1 &e alterne para o novo servidor X (pode ser necessário configurar a autorização X usando xauth(1)).

Como você pode ver, o servidor X faz muito pouco, não desenha barras de título, não minimiza / iconifica a janela, não gerencia o posicionamento da janela ... É claro, você pode controlar o posicionamento da janela manualmente executando um comando como xterm -geometry -0-0, mas normalmente você vai ter um cliente especial X fazendo as coisas acima. Esse cliente é chamado de gerenciador de janelas . Só pode haver um gerenciador de janelas ativo por vez. Se você ainda tiver aberto o servidor X nua dos comandos anteriores, você pode tentar executar um gerenciador de janelas sobre ele, como twm, metacity, kwin, compiz, larswm, pawm, ...

Como dissemos, o X realiza apenas operações de baixo nível e não fornece conceitos de nível superior como botões, menus, barras de ferramentas, ... Estes são fornecidos por bibliotecas chamadas kits de ferramentas , por exemplo: Xaw, GTK, Qt, FLTK, ...

Os ambientes de área de trabalho são coleções de programas projetados para fornecer uma experiência unificada ao usuário. Portanto, os ambientes de área de trabalho geralmente fornecem painéis, ativadores de aplicativos, bandejas do sistema, painéis de controle, infraestrutura de configuração (onde salvar as configurações). Alguns ambientes de área de trabalho bem conhecidos são o KDE (construído usando o kit de ferramentas Qt), o Gnome (usando o GTK), o Enlightenment (usando suas próprias bibliotecas de kits de ferramentas), ...

Alguns efeitos modernos da área de trabalho são melhores usando hardware 3D. Portanto, um novo componente aparece, o gerente composto . Uma extensão X, a extensão XComposite, envia o conteúdo da janela para o gerenciador composto. O gerenciador de compostos converte esses conteúdos em texturas e usa o hardware 3D via OpenGL para compor de várias maneiras (mistura alfa, projeções 3D, ...).

Há pouco tempo, o servidor X conversava diretamente com dispositivos de hardware. Uma parte significativa desse manuseio de dispositivo foi movida para o kernel do SO: DRI (permitindo acesso ao hardware 3D pelo X e clientes de renderização direta), evdev (interface unificada para o manuseio do dispositivo de entrada), KMS (configuração do modo de gráficos em movimento para o kernel) , GEM / TTM (gerenciamento de memória de textura).

Portanto, com a complexidade do manuseio de dispositivos agora principalmente fora do X, ficou mais fácil experimentar sistemas de janelas simplificados. Wayland é um sistema de janelas baseado no conceito de gerenciador composto, ou seja, o sistema de janelas é o gerenciador composto. Wayland utiliza o manuseio do dispositivo que saiu do X e é renderizado usando o OpenGL.

Quanto ao Unity, é um ambiente de desktop projetado para ter uma interface de usuário adequada para netbooks.

A pilha tradicional é construída sobre três componentes principais:

• Servidor X que lida com a exibição
• Gerenciador de janelas que coloca janelas em quadros, manipula janelas minimizadas etc. Isso faz parte da separação de mecanismo da política no Unix
• Clientes que executam tarefas úteis como exibindo o site stackexchange. Eles podem usar o protocolo X diretamente (suicídio), usar xlib ou xcb (um pouco mais fácil) ou usar um kit de ferramentas como GTK + ou QT.

A arquitetura X foi feita em rede, permitindo que os clientes estivessem em um host e servidor separados.

Por enquanto, tudo bem. No entanto, essa era a imagem do caminho de volta. Hoje em dia não é a CPU que lida com os gráficos, mas a GPU. Houve várias tentativas de incorporá-lo no modelo - e colocar quando o kernel se encaixa para aumentar ainda mais.

Em primeiro lugar, foram feitas algumas suposições sobre o uso da placa gráfica. Por exemplo, apenas a renderização na tela foi assumida. Não consigo encontrar essas informações na wikipedia no momento, mas o DRI 1 também assumiu que apenas um aplicativo usará o OpenGL ao mesmo tempo (não posso citar imediatamente, mas posso desenterrar o bug onde estava próximo ao WONTFIX com nota para aguardar o DRI 2)

Algumas soluções temporárias foram propostas para renderização indireta (necessária para o WM composto):

• XGL - proposição inicial que suporta aplicativos que conversam diretamente com o cartão
• AIGLX - proposição aceita que usa propriedades de rede do protocolo OpenGL
• Solução proprietária da NVidia

Os trabalhos sobre arquitetura mais recente (DRI 2) foram iniciados. Isso inclui:

• Suporte no kernel para manipulação de memória (GEM / TTM)
• O modo de configuração do kernel (KMS) permite alterar a resolução no kernel, evitando atrasos ao alternar entre o X e o console e alguns outros recursos (como exibir mensagem em pânico mesmo que o X esteja em execução - que o IIRC está planejado para ser implementado).

De alguma forma ortogonal para mover para o kernel, o trabalho com os drivers Gallium foi iniciado. A biblioteca Mesa começou como implementação do OpenGL na CPU e, em seguida, começou a usar a aceleração da GPU. Sempre foi apertado para o OpenGL. No OpenGL 3.0, o modelo mudou significativamente e a reescrita da biblioteca era inevitável. No entanto, eles estão aproveitando a oportunidade para dividir o código em várias camadas, extraindo código comum e fornecendo API de baixo nível, permitindo implementar várias APIs 3D - permitindo, por exemplo, que o Wine forneça DirectX conversando diretamente com o Gallium, em vez de passar pelo OpenGL Camada da API (que pode não ter chamadas diretas de 1 a 1).

Wayland é um projeto que considera o exposto um pouco complicado e com "história" demais. O design de 1984 (embora altamente modificado e adaptado) não corresponde ao início de 21 c. de acordo com os proponentes.

Supõe-se oferecer maior flexibilidade e melhor desempenho, embora ainda estejam faltando alguns recursos importantes, como suporte completo a OpenGL (e importante para alguns - suporte de rede).

Um pouco mais sobre ambientes de desktop e gerenciadores de janelas. O gerenciador de janelas é um aplicativo responsável por como a janela se comportará - por exemplo, é responsável por gerenciar os espaços de trabalho, desenhar a barra de título (a coisa na parte superior da tela com o título windo e os botões minimizar / maximizar / fechar) etc.

Em primeiro lugar, apenas WM mínimo foi usado, mas depois o usuário começou a desejar ambientes de desktop - ou seja, versão com mais recursos, que incluía início de menu, plano de fundo da área de trabalho etc.

Depois de algum tempo, o WM composto foi introduzido, que usa OpenGL e renderização indireta para fazer seu trabalho. Eles fornecem não apenas efeitos gráficos, mas também permitem uma implementação mais fácil de alguns recursos de acessibilidade (como lupa).

Primeiro de tudo, não há realmente nenhuma pilha de gráficos do Linux. O Linux não possui recursos de exibição gráfica.

No entanto, os aplicativos Linux podem usar telas gráficas e existem vários sistemas diferentes para fazer isso. Os mais comuns são todos criados em cima do X windows.

X é um protocolo de rede porque no meio de uma pilha de protocolos X você pode ter uma rede como um componente padrão. Vejamos um caso de uso específico. Um físico em Berlim quer fazer um experimento no CERN na Suíça com um dos coletores de partículas nucleares. Ele faz logon remotamente e executa um programa de análise de dados em uma das matrizes de supercomputadores do CERN e representa graficamente os resultados em sua tela.

Em Berlim, o físico possui um dispositivo X-terminal executando algum software X-server que fornece uma capacidade de exibição gráfica para aplicativos remotos. O software do servidor X possui um buffer de quadros que fala com o driver de dispositivo específico para o hardware específico. E o software X-server fala o protocolo X. Portanto, as camadas podem ser dispositivo gráfico-> driver de dispositivo-> buffer de quadro-> servidor X-> protocolo X.

Em seguida, na Suíça, o aplicativo se conecta a uma exibição usando o protocolo X e envia comandos de exibição gráfica como "desenhar retângulo" ou "combinação alfa". O aplicativo provavelmente usa uma biblioteca gráfica de alto nível e essa biblioteca provavelmente, por sua vez, será baseada em uma biblioteca de nível inferior. Por exemplo, o aplicativo pode ser escrito em Python usando o kit de ferramentas WxWidget, construído sobre o GTK, que usa uma biblioteca chamada Cairo para os principais comandos de desenho gráfico. Também pode haver OPENGL também no topo do Cairo. As camadas podem ser assim: WxWidgets-> GTK-> Cairo-> X Toolkit-> protocolo X. Claramente, é o protocolo intermediário que conecta as coisas e, como o Linux também suporta soquetes UNIX, um transporte completamente interno de dados, esses dois tipos de coisas podem ser executados em uma máquina, se você desejar.

X se refere ao protocolo e a qualquer coisa fundamental da arquitetura, como o servidor X que executa a exibição gráfica, o dispositivo apontador e o teclado.

GTK e QT são duas bibliotecas GUI de uso geral que suportam janelas, caixas de diálogo, botões, etc.

O GNOME e o KDE são dois ambientes de desktop que gerenciam as janelas na área de trabalho gráfica, fornecem applets e coisas úteis, como barras de botões. Eles também permitem que vários aplicativos se comuniquem através do servidor X (dispositivo do terminal X), mesmo se os aplicativos estiverem sendo executados em computadores remotos diferentes. Por exemplo, copiar e colar é uma forma de comunicação entre aplicativos. O GNOME é construído sobre o GTK. O KDE é construído sobre o QT. E é possível executar aplicativos GNOME em uma área de trabalho do KDE ou aplicativos KDE em uma área de trabalho GNOME, porque todos funcionam com o mesmo protocolo X subjacente.

Esta é sua organização, você aprenderá mais com esta figura que em várias páginas de texto:

O Linux na área de trabalho e alguns servidores ainda são todos os gráficos X e de buffer de quadro. Sob a janela X - Vem GTK + e Qt, SIM ambos usam o sistema X, novamente existem muitos ambientes de desktop - Gnome, o KDE usa a tela X e suas conchas, etc.

Aliás, houve um vídeo recente do linux conf (http://blip.tv/file/4693305/). Keith Packard, da Intel, falou sobre X e GL * Foi interessante.