Comment ça marche (Gnu/Linux + X11)
Aperçu
Il ressemble à ceci (pas à l'échelle)
┌───────────────────────────────────────────────┐
│ User │
│ ┌─────────────────────────────────────────┤
│ │ Application │
│ │ ┌──────────┬─────┬─────┬─────┤
│ │ │ ... │ SDL │ GTK │ QT │
│ │ ├──────────┴─────┴─────┴─────┤
│ │ │ xLib │
│ │ ├────────────────────────────┤
├─────┴───┬────────┴──┐ X11 │
│ Gnu │ Libraries │ Server │
│ Tools │ │ │
├─────────┘ │ │
├─────────────────────┤ │
│ Linux (kernel) │ │
├─────────────────────┴─────────────────────────┤
│ Hardware │
└───────────────────────────────────────────────┘
Nous voyons sur le diagramme que X11 parle principalement avec le matériel. Cependant, il doit parler via le noyau pour avoir initialement accès à ce matériel.
Je suis un peu flou sur les détails (et je pense que cela a changé depuis la dernière fois que je l'ai examiné). Il y a un appareil /dev/mem qui donne accès à l'ensemble de la mémoire (je pense à la mémoire physique), comme la plupart du matériel graphique est mappé en mémoire, ce fichier (voir tout est un fichier) peut être utilisé pour y accéder. X11 ouvrirait le fichier (le noyau utilise les autorisations de fichier pour voir s'il peut le faire), alors X11 utilise mmap pour mapper le fichier dans la mémoire virtuelle (le faire ressembler à de la mémoire), maintenant la mémoire ressemble à de la mémoire. Après mmap , le noyau n'est pas impliqué.
X11 doit connaître les différents matériels graphiques, car il y accède directement, via la mémoire.
(cela peut avoir des changements, en particulier le modèle de sécurité, peut ne plus donner accès à TOUS de la mémoire.)
Linux
En bas se trouve Linux (le noyau) :une petite partie du système. Il fournit l'accès au matériel et implémente la sécurité.
Gnou
Puis Gnu (Bibliothèques ; bash ; outils : ls, etc. ; compilateur C, etc.). La plupart du système d'exploitation.
Serveur X11 (par exemple x.org)
Puis X11 (Or Wayland, ou ...), le sous-système GUI de base. Cela s'exécute en mode utilisateur (en dehors du noyau) :c'est juste un autre processus, avec quelques privilèges. Le noyau n'intervient pas, sauf pour donner accès au matériel. Et fournir une communication inter-processus, afin que d'autres processus puissent communiquer avec le serveur X11.
Bibliothèque X11
Une abstraction simple pour vous permettre d'écrire du code pour X11.
Bibliothèques graphiques
Viennent ensuite les bibliothèques telles que qt, gtk, sdl :elles facilitent l'utilisation de X11 et fonctionnent sur d'autres systèmes tels que wayland, Windows de Microsoft ou MacOS.
Applications
Les applications se trouvent au-dessus des bibliothèques.
Quelques points d'entrée de bas niveau, pour la programmation
xlib
L'utilisation de xlib est un bon moyen d'en savoir plus sur X11. Cependant, lisez d'abord sur X11.
SDL
SDL vous donnera un accès de bas niveau, direct aux plans de bits sur lesquels vous pourrez dessiner directement.
De plus en plus bas
Si vous voulez descendre plus bas, je ne sais pas quelles sont les bonnes options actuelles, mais voici quelques idées.
- Obtenez un vieil Amiga ou un simulateur. Et une bonne documentation. par exemple. https://archive.org/details/Amiga_System_Programmers_Guide_1988_Abacus/mode/2up (j'avais 2 livres, celui-ci et similaire).
- Regardez ce qui peut être fait sur un raspberry pi. Je n'ai pas examiné cela.
Liens
X11
https://en.wikipedia.org/wiki/X_Window_System
Méthodes modernes
L'écriture de ceci a suscité mon intérêt, alors j'ai jeté un coup d'œil à la manière moderne et rapide de le faire. Voici quelques liens :
https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/
La réponse de ctrl-alt-delor vous donne un bon aperçu de l'architecture générale. Pour une approche plus pratique, je vous donne une réponse concernant "rien d'autre que le noyau Linux et la programmation en C".
J'aime écrire directement dans le frame-buffer de temps en temps. Le pilote de périphérique frame-buffer fera toutes les tâches fastidieuses proches du matériel "comment cela finira-t-il par se retrouver sur un écran" pour vous. Vous pouvez le faire tout de suite avec un root shell :
echo -n -e '\x00\x00\xFF' > /dev/fb0
Il définit le tout premier pixel (en haut à gauche) en rouge sur mon framebuffer 32 bits :
Vous pouvez totalement le faire depuis C en ouvrant /dev/fb0 et en écrivant des octets. La cartographie de la mémoire peut devenir votre ami. Cela ne fonctionne que sans serveur X ou dans une console virtuelle. Appuyez sur Ctrl+Alt+F1 pour y accéder.
PS :Visualiser des données aléatoires comme le mouvement de votre souris peut aussi être amusant :
cat /dev/input/mouse0 > /dev/fb0
PPS :Veuillez également noter que pratiquement toutes les applications de bureau du monde réel souhaitent un accès plus direct au matériel pour certaines fonctionnalités sophistiquées telles que l'accélération matérielle pour le dessin, la 3D et le rendu vidéo. Le simple dispositif de mémoire tampon de trame ne fera rien de tout cela.
Je recommanderais fortement de commencer par ncurses.
Contrairement aux systèmes graphiques plus complexes, il est basé uniquement sur du texte, il n'est donc pas nécessaire de s'enliser dans les détails des pilotes d'écran et des bibliothèques graphiques. Cependant, les principes de base consistant à placer des fenêtres sur un écran, à déplacer le focus entre les fenêtres, etc., restent valables. Et vous pouvez toujours faire du dessin, au niveau des blocs de caractères simples et de l'art ASCII.
Bien sûr, vous construisez toujours cela au-dessus d'une bibliothèque, mais c'est une bibliothèque que vous pouvez facilement comprendre. Et plus que ça, c'est une bibliothèque où le code source est disponible librement, assez bien documenté, et pas trop impénétrable si vous voulez le lire. Vous pouvez même le modifier vous-même si vous le souhaitez. Ou vous pouvez consulter toutes les fonctions de la bibliothèque pour trouver ce que l'API doit être, et l'écrire vous-même à partir de zéro en fonction de cette conception.