desenv-web-rp.com

Como uma GUI do linux funciona no nível mais baixo?

Estou basicamente tentando descobrir como alguém criaria uma GUI do zero, sem nada além do kernel do linux e da programação em C.

Não estou procurando criar um ambiente de área de trabalho da GUI do zero, mas gostaria de criar alguns aplicativos de área de trabalho e, na minha busca por conhecimento, todas as informações que consegui encontrar estão nas APIs e kits de ferramentas da GUI. Eu gostaria de saber, pelo menos para minha compreensão dos fundamentos de como a GUI do linux é feita, como alguém criaria um ambiente de GUI ou uma aplicação de GUI sem usar APIs ou kits de ferramentas.

Gostaria de saber se, por exemplo:

  1. aPIs e kits de ferramentas existentes funcionam por meio de chamadas do sistema ao kernel (e o kernel é responsável no nível mais baixo pela construção de uma imagem da GUI em pixels ou algo assim)

  2. esses kits de ferramentas executam syscalls que simplesmente transmitem informações para os drivers de tela (existe um formato padrão para o envio dessas informações que todos os drivers de tela cumprem ou as APIs da GUI precisam ser capazes de emitir essas informações em vários formatos, dependendo da tela/driver específico? ) e também se isso for aproximadamente verdade, o kernel do linux bruto normalmente envia apenas informações para a tela na forma de caracteres de 8 bits?

Eu realmente quero entender o que acontece entre o kernel do linux e o que vejo na minha tela (controle/fluxo de informações através de software e hardware, se você souber, qual o formato da informação, etc.). Apreciaria muito uma explicação detalhada, entendo que isso pode ser um problema para explicar em detalhes suficientes, mas acho que essa explicação seria um ótimo recurso para outras pessoas curiosas e que estão aprendendo. Por um contexto, eu sou um estudante de ciência da computação do terceiro ano que recentemente começou a programar em C para o meu curso de Programação de Sistemas e tenho um entendimento intermediário (ou assim o descreveria) de linux e programação. Mais uma vez obrigado a quem me ajuda !!!

46
poopoopeepee123

Como funciona (Gnu/Linux + X11)

Visão geral

Parece algo assim (não desenha em escala)

┌───────────────────────────────────────────────┐
│                       User                    │
│     ┌─────────────────────────────────────────┤
│     │             Application                 │
│     │            ┌──────────┬─────┬─────┬─────┤
│     │            │      ... │ SDL │ GTK │ QT  │
│     │            ├──────────┴─────┴─────┴─────┤
│     │            │            xLib            │
│     │            ├────────────────────────────┤
├─────┴───┬────────┴──┐         X11             │
│   Gnu   │ Libraries │        Server           │
│   Tools │           │                         │
├─────────┘           │                         │ 
├─────────────────────┤                         │
│   Linux (kernel)    │                         │
├─────────────────────┴─────────────────────────┤
│                    Hardware                   │
└───────────────────────────────────────────────┘

Vimos no diagrama que o X11 fala principalmente com o hardware. No entanto, ele precisa conversar através do kernel, para obter inicialmente acesso a esse hardware.

Estou um pouco confuso com os detalhes (e acho que mudou desde a última vez que os examinei). Existe um dispositivo /dev/mem que dá acesso a toda a memória (acho que a memória física), como a maior parte do hardware gráfico é mapeada para memória, esse arquivo (veja tudo o que é um arquivo) pode ser usado para acessá-lo. O X11 abriria o arquivo (o kernel usa permissões de arquivo para verificar se é possível fazer isso) e o X11 usa mmap para mapear o arquivo na memória virtual (faça com que pareça memória), agora a memória se parece com memória. Após mmap, o kernel não está envolvido.

O X11 precisa conhecer os vários hardwares gráficos, à medida que os acessam diretamente, via memória.

(isso pode ter alterações, especificamente o modelo de segurança, não pode mais dar acesso a [~ # ~] todos os [~ # ~] da memória. )

Linux

Na parte inferior está o Linux (o kernel): uma pequena parte do sistema. Ele fornece acesso ao hardware e implementa segurança.

Gnu

Então Gnu (Bibliotecas; bash; ferramentas: ls, etc; compilador C, etc). A maior parte do sistema operacional.

Servidor X11 (por exemplo, x.org)

Depois, X11 (ou Wayland, ou ...), o subsistema básico da GUI. Isso é executado na área do usuário (fora do kernel): é apenas outro processo, com alguns privilégios. O kernel não se envolve, exceto para dar acesso ao hardware. E fornecendo comunicação entre processos, para que outros processos possam conversar com o servidor X11.

Biblioteca X11

Uma abstração simples para permitir que você escreva código para o X11.

Bibliotecas da GUI

Bibliotecas como qt, gtk, sdl, são as próximas - elas facilitam o uso do X11 e funcionam em outros sistemas, como wayland, Windows da Microsoft ou MacOS.

Formulários

Os aplicativos ficam no topo das bibliotecas.

Alguns pontos de entrada de baixo nível, para programação

xlib

Usando o xlib, é uma boa maneira de aprender sobre o X11. No entanto, faça algumas leituras sobre o X11 primeiro.

SDL

O SDL lhe dará acesso de baixo nível, direto aos planos de bits para você desenhar diretamente.

Indo mais baixo

Se você quiser ir mais baixo, não tenho certeza de quais são as boas opções atuais, mas aqui estão algumas idéias.

Ligações

X11

https://en.wikipedia.org/wiki/X_Window_System

Maneiras modernas

Escrever isso despertou meu interesse, então eu dei uma olhada no que é a maneira rápida e moderna de fazer isso. Aqui estão alguns links:

https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/

62
ctrl-alt-delor

a resposta de ctrl-alt-delor fornece uma boa visão geral da arquitetura geral. Para uma abordagem mais prática, eu lhe dou uma resposta sobre "nada além do kernel do linux e da programação em C".

Eu gosto de escrever diretamente no buffer de quadros de vez em quando. O driver de dispositivo do buffer de quadro fará todo o trabalho tedioso próximo ao hardware "como isso acabará na tela" para você. Você pode fazer isso imediatamente com um Shell raiz:

echo -n -e '\x00\x00\xFF' > /dev/fb0

Ele define o primeiro pixel (canto superior esquerdo) como vermelho no meu buffer de tela de 32 bits:

Screenshot of the framebuffer with the top left pixel red

Você pode fazer isso totalmente a partir do C, abrindo/dev/fb0 e gravando bytes. O mapeamento da memória pode se tornar seu amigo. Isso funciona apenas sem um servidor X ou em um console virtual. Pressione Ctrl + Alt + F1 para acessá-lo.

PS: Visualizar dados aleatórios como o movimento do mouse também pode ser divertido:

cat /dev/input/mouse0 > /dev/fb0

PPS: Observe também que praticamente qualquer aplicativo de desktop do mundo real deseja acesso mais direto ao hardware para algumas coisas sofisticadas, como aceleração de hardware para desenho, 3D e renderização de vídeo. O simples dispositivo de buffer de quadros não fará nada disso bem.

30
Hermann

Eu recomendo fortemente começar com ncurses .

Ao contrário dos sistemas gráficos mais complexos, ele é baseado apenas em texto, portanto, não há necessidade de se atolar nos detalhes dos drivers de tela e bibliotecas gráficas. No entanto, os princípios básicos de colocar janelas em uma tela, mover o foco entre janelas e assim por diante, ainda são verdadeiros. E você ainda pode fazer alguns desenhos, no nível de blocos de um caractere e ASCII art.

É claro que você ainda está construindo isso no topo de uma biblioteca, mas é uma biblioteca que você pode entender facilmente. E mais do que isso, é uma biblioteca em que o código fonte está disponível gratuitamente, é bem documentado e não é impenetrável se você quiser lê-lo. Você pode até modificá-lo você mesmo, se quiser. Ou você pode examinar todas as funções da biblioteca para encontrar o que a API precisa ser e escrevê-la do zero, com base nesse design.

6
Graham

O SunOS 5 tinha a biblioteca DGA, que fornecia acesso independente do dispositivo aos diferentes adaptadores gráficos cg [3,6,14], TCX ou LEO, que também apoiavam o Doom no SPARC máquinas.

o cg6 era de 8 bits, geralmente usado no X11 como visual pseudocolor, mas também poderia fornecer uma cor verdadeira de 8 bits, enquanto o tcx e o leo são um buffer de quadro de exibição 3d acelerado em 24 bits (pseudocolor = um byte no videoram é um índice em uma grande tabela que fornece um valor de 3x8 RGB, o conteúdo da tabela pode ser alterado facilmente.) O cg3 tinha aproximadamente a mesma capacidade, mas não foi acelerado (os designers do cg6 começaram depois de outra empresa ... nVidia.)

Os dispositivos posteriores, como o PGX, que era baseado no chipset ATI Rage Pro, não podiam suportar truecolor e pseudocolor ao mesmo tempo, como os anteriores. Isso forçou o usuário a escolher entre aplicativos antigos escritos para o modelo de pseudocolor (ou atualizar o sw, se possível) e executar apenas aplicativos orientados para cores reais.

O pseudocolor existia basicamente porque o que era um videoram era muito caro em meados dos anos 80 até 1992, aproximadamente. Um monitor colorido que suportava uma resolução de tipo de estação de trabalho utilizável também era bastante caro (o Sun 2 em preto e branco de 1984 tinha uma resolução de 1152x864, enquanto um MG1 de 1989 ou mais tinha 1600x1280, mas preto e branco).

Escrevo isso porque quero mostrar os diferentes requisitos que o X11 tinha para oferecer suporte.

2
Stefan Skoglund