Início / unix / Perguntas / 568634
Accepted
poopoopeepee123
Asked: 2020-02-20 22:43:04 +0800 CST

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

  • 772

Estou basicamente tentando descobrir como alguém faria uma GUI a partir do zero com nada além do kernel linux e programação em C.

Não estou procurando criar um ambiente de desktop GUI a partir do zero, mas gostaria de criar alguns aplicativos de desktop e em minha busca por conhecimento, todas as informações que consegui encontrar estão em APIs e kits de ferramentas de GUI. Eu gostaria de saber, pelo menos para minha compreensão dos fundamentos de como a GUI do linux é feita, como alguém faria um ambiente de GUI ou um aplicativo de GUI sem usar APIs ou kits de ferramentas.

Pergunto-me se por exemplo:

  1. APIs e kits de ferramentas existentes funcionam por meio de chamadas de sistema para o kernel (e o kernel é responsável no nível mais baixo por construir uma imagem GUI em pixels ou algo assim)

  2. esses kits de ferramentas executam syscalls que simplesmente passam informações para drivers de tela (existe um formato padrão para enviar essas informações que todos os drivers de tela obedecem ou as APIs GUI precisam ser capazes de produzir essas informações em vários formatos, dependendo da tela/driver específico? ) e também se isso for aproximadamente verdade, o kernel linux bruto geralmente envia 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 eu vejo na minha tela (controle/fluxo de informações através de software e hardware, se você souber, qual formato a informação leva, etc). Eu apreciaria muito uma explicação detalhada, eu entendo que isso pode ser uma merda para explicar em detalhes suficientes, mas acho que tal explicação seria um ótimo recurso para outros que estão curiosos e aprendendo. Por contexto, sou um estudante de sci do 3º ano que começou recentemente a programar em C para o meu curso de programação de sistemas e tenho uma compreensão intermediária (ou assim eu descreveria) de linux e programação. Mais uma vez obrigado a quem me ajudar!!!

linux linux-kernel

4 respostas

  1. Best Answer

    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                   │
└───────────────────────────────────────────────┘

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

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

    O X11 precisa conhecer os diversos hardwares gráficos, pois o acessa diretamente, via memória.

    (isso pode ter alterações, especificamente o modelo de segurança, pode não dar mais acesso a TODA a memória.)

    Linux

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

    Gnu

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

    Servidor X11 (ex.xorg)

    Então X11 (Ou Wayland, ou ...), o subsistema GUI básico. Isso é executado na área do usuário (fora do kernel): é apenas mais um 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 X11.

    Bibliotecas de 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 xlib, é uma boa maneira de aprender sobre o X11. No entanto, faça alguma leitura 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.

    Links

    X11

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

    Maneiras modernas

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

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

    • 68

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

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

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

    Ele define o primeiro pixel (canto superior esquerdo) para vermelho no meu framebuffer de 32 bits:

    Captura de tela do framebuffer com o pixel superior esquerdo vermelho

    Você pode fazer isso totalmente de dentro do C abrindo /dev/fb0 e escrevendo bytes. O mapeamento de memória pode se tornar seu amigo. Isso só funciona 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 dispositivo de buffer de quadro simples não fará nada disso bem.

    • 34

  3. Eu recomendo fortemente começar com ncurses .

    Ao contrário de sistemas gráficos mais complexos, ele é baseado puramente em texto, portanto, não há necessidade de se preocupar com os 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, ao nível de blocos de caracteres únicos e arte ASCII.

    Claro que você ainda está construindo isso em cima de uma biblioteca, mas é uma biblioteca que você pode entender facilmente. E mais do que isso, é uma biblioteca onde o código-fonte está disponível gratuitamente, bastante bem documentado e não muito 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 descobrir o que a API precisa ser e escrevê-la do zero com base nesse design.

    • 6

  4. O SunOS 5 tinha a biblioteca DGA, que fornecia acesso independente de dispositivo aos diferentes adaptadores gráficos cg[3,6,14], TCX ou LEO, que também suportava o DOOM nas máquinas SPARC.

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

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

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

    Escrevo isso porque quero mostrar os diferentes requisitos que o X11 teve que suportar.

    • 1

relate perguntas