Como a pilha de gráficos do Linux é organizada?

Question

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

    

Answer 1

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

O servidor X faz apenas operações de baixo nível, como criar e destruir janelas, fazer operações de desenho (hoje em dia a maioria dos desenhos é feita no cliente e enviada como uma imagem para o servidor), enviando eventos para janelas, ... veja como um servidor X faz pouco executando X :1 & (use qualquer número que não seja usado por outro servidor X) ou Xephyr :1 & (o Xephyr executa um servidor X embutido no seu servidor X atual) e executando xterm -display :1 & e alternando para o novo servidor X (talvez seja necessário configurar a autorização X usando xauth(1) ).

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

Como dissemos, o X faz 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 toolkits , por exemplo: Xaw , GTK, Qt, FLTK, ...

Os ambientes de área de trabalho são conjuntos de programas projetados para fornecer uma experiência de usuário unificada. Portanto, os ambientes de área de trabalho geralmente fornecem painéis, lançadores de aplicativos, bandejas do sistema, painéis de controle e infra-estrutura de configuração (onde salvar configurações). Alguns ambientes de desktop conhecidos são o KDE (construído usando o kit de ferramentas Qt), o Gnome (usando GTK), o Enlightenment (usando suas próprias bibliotecas de toolkit), ...

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

Não faz muito tempo, o servidor X conversou diretamente com os dispositivos de hardware. Uma parte significativa do tratamento desse dispositivo foi transferida para o kernel do SO: DRI (permitindo acesso a hardware 3D por clientes de renderização direta X e ), evdev (interface unificada para manipulação de dispositivo de entrada), KMS configuração do modo gráfico para o kernel), GEM / TTM (gerenciamento de memória de textura).

Assim, com a complexidade do manuseio do dispositivo agora principalmente fora do X, ficou mais fácil experimentar sistemas simplificados de janelas. O Wayland é um sistema de janelas baseado no conceito do gerenciador de composição, ou seja, o sistema de janelas é o gerenciador de composição. O Wayland faz uso do manuseio do dispositivo que saiu do X e renderiza usando o OpenGL.

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

    

Answer 2

A pilha tradicional é construída sobre 3 componentes principais:

• servidor X que manipula a exibição
• Gerenciador de janelas que coloca janelas em quadros, manipula janelas minimizando etc. Isso faz parte da separação do mecanismo da política no Unix
• Clientes que realizam 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 tornou-se rede, portanto, permitindo que os clientes estejam em host separado, em seguida, servidor.

Até aí tudo bem. No entanto, essa foi a imagem do caminho de volta. Hoje em dia não é a CPU que lida com os gráficos, mas com a GPU. Houve várias tentativas de incorporá-lo no modelo - e colocar quando o kernel entrar em ação para maior extensão.

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 essa informação na wikipedia agora, mas a DRI 1 também assumiu que apenas uma aplicação usará o OpenGL ao mesmo tempo (não posso citar imediatamente, mas posso descobrir onde estava perto, como WONTFIX com nota para esperar para a DRI 2).

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

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

Os trabalhos na arquitetura mais nova (DRI 2) foram iniciados. Isso incluiu:

• Suporte no kernel para manipulação de memória (GEM / TTM)
• Ajuste de modos do kernel (KMS) permitindo alterar a resolução no kernel, evitando atrasos ao alternar entre o console X e o console & alguns outros recursos (como exibir mensagens no pânico, mesmo se o X estiver rodando - que o IIRC está planejado para ser implementado).

De alguma forma ortogonal para mover para o kernel o trabalho em drivers Gallium foram iniciados. A biblioteca do Mesa começou como implementação do OpenGL na CPU e depois começou a usar a aceleração da GPU. Ele sempre foi ajustado ao OpenGL. No OpenGL 3.0, o modelo mudou significativamente e a reescrita da biblioteca foi 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 falando diretamente para o Gallium ao invés de usar o OpenGL. Camada de API (que pode não ter chamadas diretas 1-1).

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

É suposto oferecer maior flexibilidade e melhor desempenho, embora ainda faltem alguns recursos importantes, como suporte total ao OpenGL (e importante para alguns - suporte de rede).

Um pouco mais sobre ambientes de área de trabalho e gerenciadores de janelas. O gerenciador de janelas é um aplicativo responsável por como a janela irá se comportar - por exemplo, é responsável pelo gerenciamento de espaços de trabalho, desenho de barra de título (a coisa no topo da tela com título windo e botões minimizar / maximizar / fechar) etc.

Primeiro foi usado apenas o WM mínimo, mas depois o usuário começou a querer ambientes de desktop - por exemplo, a versão mais em destaque, que incluía menu start, desktop background etc. No entanto, a maioria das partes do ambiente de desktop não é um gerenciador de janelas.

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

    

Answer 3

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

No entanto, os aplicativos Linux podem usar exibições gráficas e existem vários sistemas diferentes para fazer isso. Os mais comuns são todos construídos 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 componente padrão. Vamos ver um caso de uso específico. Um físico em Berlim quer fazer uma experiência no CERN na Suíça com um dos colecionadores de partículas nucleares. Ele faz o login remotamente e executa um programa de análise de dados em um dos arrays de supercomputadores do CERN e grava os resultados em sua tela.

Em Berlim, o físico tem um dispositivo X-terminal rodando alguns softwares de servidor X que fornece uma capacidade de exibição gráfica para aplicações remotas. O software do servidor X tem um framebuffer que fala com o driver de dispositivo específico para o hardware específico. E o software do servidor X fala o protocolo X. Assim, as camadas podem ser um dispositivo gráfico - > driver de dispositivo > buffer de quadro - > servidor X - > protocolo X.

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

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

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

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

    

Answer 4

Esta é a sua organização. Você aprenderá mais com esta imagem que vem de várias páginas de texto:

    

Answer 5

O Linux na área de trabalho e alguns servidores ainda são gráficos X e frame buffer. Sob a janela X - Vem GTK + e Qt, YES BOTH usa o sistema X, novamente há muitos ambientes de desktop - o Gnome, o KDE usa o display X e seus shells, etc.

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