Comment la pile graphique Linux est-elle organisée?

Quelqu'un peut-il expliquer (si tout va bien avec une image), comment la pile graphique linux est-elle organisée? J'entends tout le temps parler de X / GTK / GNOME / KDE, etc., mais je n'ai vraiment aucune idée de ce qu'ils font réellement et comment ils interagissent entre eux et avec d'autres parties de la pile. Comment Unity et Wayland s'intègrent-ils?

Le système X Window utilise une architecture client-serveur. Le serveur X s'exécute sur la machine qui a l'affichage (moniteurs + périphériques d'entrée), tandis que les clients X peuvent s'exécuter sur n'importe quelle autre machine et se connecter au serveur X en utilisant le protocole X (pas directement, mais plutôt en utilisant une bibliothèque, comme Xlib, ou le XCB événementiel non bloquant plus moderne). Le protocole X est conçu pour être extensible et possède de nombreuses extensions (voir xdpyinfo(1)).

Le serveur X ne fait que des opérations de bas niveau, comme créer et détruire des fenêtres, faire des opérations de dessin (de nos jours la plupart des dessins sont effectués sur le client et envoyés comme image au serveur), envoyer des événements à Windows, ... Vous pouvez voir combien peu un serveur X le fait en exécutant X :1 &(utilisez un nombre qui n'est pas déjà utilisé par un autre serveur X) ou Xephyr :1 &(Xephyr exécute un serveur X intégré à votre serveur X actuel), puis en exécutant xterm -display :1 &et en basculant vers le nouveau serveur X (vous devrez peut-être configurer l'autorisation X en utilisant xauth(1)).

Comme vous pouvez le voir, le serveur X fait très peu, il ne dessine pas de barres de titre, ne minimise / iconifie pas les fenêtres, ne gère pas le placement des fenêtres ... Bien sûr, vous pouvez contrôler le placement des fenêtres en exécutant manuellement une commande comme xterm -geometry -0-0, mais vous aurez généralement un client X spécial qui fait les choses ci-dessus. Ce client est appelé gestionnaire de fenêtres . Il ne peut y avoir qu'un seul gestionnaire de fenêtres actif à la fois. Si vous avez encore ouvert le serveur X nu des commandes précédentes, vous pouvez essayer d'exécuter un gestionnaire de fenêtres dessus, commetwm , metacity, kwin, compiz, larswm, pawm, ...

Comme nous l'avons dit, X ne fait que des opérations de bas niveau, et ne fournit pas de concepts de plus haut niveau comme boutons poussoirs, menus, barres d'outils, ... Ceux-ci sont fournis par des bibliothèques appelées toolkits , par exemple: Xaw, GTK, Qt, FLTK, ...

Les environnements de bureau sont des ensembles de programmes conçus pour offrir une expérience utilisateur unifiée. Les environnements de bureau fournissent généralement des panneaux, des lanceurs d'applications, des plateaux système, des panneaux de contrôle, une infrastructure de configuration (où enregistrer les paramètres). Certains environnements de bureau bien connus sont KDE (construit en utilisant la boîte à outils Qt), Gnome (en utilisant GTK), Enlightenment (en utilisant ses propres bibliothèques de boîte à outils), ...

Certains effets de bureau modernes sont mieux réalisés à l'aide de matériel 3D. Un nouveau composant apparaît donc, le gestionnaire composite . Une extension X, l'extension XComposite, envoie le contenu de la fenêtre au gestionnaire composite. Le gestionnaire de composites convertit ces contenus en textures et utilise du matériel 3D via OpenGL pour les composer de nombreuses façons (mélange alpha, projections 3D, ...).

Il n'y a pas si longtemps, le serveur X parlait directement aux périphériques matériels. Une partie importante de cette gestion de périphérique a été déplacée vers le noyau du système d'exploitation: DRI (autorisant l'accès au matériel 3D par X et les clients de rendu direct), evdev (interface unifiée pour la gestion des périphériques d'entrée), KMS (déplacement du paramètre de mode graphique vers le noyau) , GEM / TTM (gestion de la mémoire de texture).

Ainsi, avec la complexité de la gestion des périphériques maintenant principalement en dehors de X, il est devenu plus facile d'expérimenter avec des systèmes de fenêtres simplifiés. Wayland est un système de fenêtres basé sur le concept de gestionnaire composite, c'est-à-dire que le système de fenêtres est le gestionnaire composite. Wayland utilise la gestion des périphériques qui a quitté X et effectue le rendu à l'aide d'OpenGL.

Quant à Unity, c'est un environnement de bureau conçu pour avoir une interface utilisateur adaptée aux netbooks.

La pile traditionnelle est construite sur 3 composants principaux:

• Serveur X qui gère l'affichage
• Gestionnaire de fenêtres qui place les fenêtres dans des cadres, gère la réduction des fenêtres, etc. Cela fait partie de la séparation du mécanisme de la politique sous Unix
• Clients qui effectuent des tâches utiles comme l'affichage du site Web stackexchange. Ils peuvent utiliser directement le protocole X (suicide), utiliser xlib ou xcb (légèrement plus facile) ou utiliser une boîte à outils telle que GTK + ou QT.

L'architecture X a été réalisée en réseau, permettant ainsi aux clients d'être sur un hôte séparé puis sur un serveur.

Jusqu'ici tout va bien. Mais c'était l'image du chemin du retour. De nos jours, ce n'est pas le CPU qui gère les graphiques mais le GPU. Il y a eu diverses tentatives pour l'incorporer dans le modèle - et le placer lorsque le noyau est en place pour s'étendre davantage.

Tout d'abord, certaines hypothèses ont été émises concernant l'utilisation de la carte graphique. Par exemple, seul le rendu à l'écran a été supposé. Je ne peux pas trouver ces informations sur wikipedia pour le moment mais DRI 1 a également supposé qu'une seule application utiliserait OpenGL en même temps (je ne peux pas citer immédiatement mais je peux creuser le bogue là où il était proche de WONTFIX avec une note à attendre pour DRI 2).

Quelques solutions temporaires ont été proposées pour le rendu indirect (nécessaire pour WM composite):

• XGL - première proposition prenant en charge les applications parlant directement à la carte
• AIGLX - proposition acceptée qui utilise les propriétés de réseau du protocole OpenGL
• Solution propriétaire de NVidia

Les travaux sur une architecture plus récente (DRI 2) ont commencé. Cela comprenait:

• Prise en charge du noyau pour la gestion de la mémoire (GEM / TTM)
• Réglage du mode du noyau (KMS) permettant de changer la résolution dans le noyau, évitant ainsi les retards lors du basculement entre X et la console et quelques autres fonctionnalités (comme afficher un message de panique même si X est en cours d'exécution - que l'IIRC devrait être implémenté).

D'une certaine manière orthogonale pour passer au noyau, les travaux sur les pilotes Gallium ont été lancés. La bibliothèque Mesa a commencé comme implémentation d'OpenGL sur le CPU, puis elle a commencé à utiliser l'accélération GPU. Il a toujours été resserré à OpenGL. Dans OpenGL 3.0, le modèle a considérablement changé et la réécriture de la bibliothèque était inévitable. Cependant, ils en profitent pour diviser le code en plusieurs couches en extrayant le code commun et en fournissant une API de bas niveau permettant d'implémenter diverses API 3D par-dessus - permettant par exemple à Wine de fournir DirectX parlant directement à Gallium au lieu de passer par l'OpenGL Couche API (qui peut ne pas avoir d'appels directs 1-1).

Wayland est un projet qui considère ce qui précède un peu compliqué et avec trop "d'histoire". Le dessin de 1984 (bien que fortement modifié et adapté) ne correspond pas au début du 21 s. selon les promoteurs.

Il est supposé offrir une plus grande flexibilité et de meilleures performances bien qu'il manque encore certaines fonctionnalités importantes comme la prise en charge complète d'OpenGL (et importante pour certains - la prise en charge réseau).

Un peu plus sur les environnements de bureau et les gestionnaires de fenêtres. Le gestionnaire de fenêtres est une application responsable du comportement de la fenêtre - par exemple, il est responsable de la gestion des espaces de travail, du dessin de la barre de titre (la chose en haut de l'écran avec le titre windo et les boutons minimiser / maximiser / fermer), etc.

Tout d'abord, une WM minimale a été utilisée, mais par la suite, l'utilisateur a commencé à vouloir des environnements de bureau - c'est-à-dire une version plus en vedette, qui comprenait le démarrage du menu, l'arrière-plan du bureau, etc. Cependant, la plupart des parties de l'environnement de bureau ne sont pas un gestionnaire de fenêtres bien qu'elles soient souvent intégrées.

Après un certain temps, le WM composite a été introduit qui utilise OpenGL et le rendu indirect pour faire son travail. Ils fournissent non seulement des effets graphiques mais permettent également une implémentation plus facile de certaines fonctionnalités d'accessibilité (comme la loupe).

Tout d'abord, il n'y a vraiment pas de pile graphique Linux. Linux n'a pas de capacités d'affichage graphique.

Cependant, les applications Linux peuvent utiliser des affichages graphiques et il existe un certain nombre de systèmes différents pour ce faire. Les plus courants sont tous construits au-dessus de X fenêtres.

X est un protocole réseau car au milieu d'une pile de protocoles X, vous pouvez avoir un réseau en tant que composant standard. Examinons un cas d'utilisation spécifique. Un physicien de Berlin veut mener une expérience au CERN en Suisse sur l'un des collisionneurs de particules nucléaires. Il se connecte à distance et exécute un programme d'analyse de données sur l'un des matrices de superordinateurs du CERN et trace les résultats sur son écran.

À Berlin, le physicien possède un appareil X-terminal exécutant un logiciel X-server qui fournit une capacité d'affichage graphique aux applications distantes. Le logiciel X-server a un framebuffer qui communique avec le pilote de périphérique spécifique pour le matériel spécifique. Et le logiciel X-server parle le protocole X. Ainsi, les couches peuvent être un périphérique graphique-> pilote de périphérique-> tampon de trame-> serveur X-> protocole X.

Ensuite, en Suisse, l'application se connecte à un écran en utilisant le protocole X et envoie des commandes d'affichage graphique comme "dessiner un rectangle" ou "mélange alpha". L'application utilise probablement une bibliothèque graphique de haut niveau et cette bibliothèque sera, à son tour, basée sur une bibliothèque de niveau inférieur. Par exemple, l'application peut être écrite en Python à l'aide de la boîte à outils WxWidget qui est construite au-dessus de GTK qui utilise une bibliothèque appelée Cairo pour les principales commandes de dessin graphique. Il peut également y avoir OPENGL au sommet du Caire. Les couches peuvent être comme ceci: WxWidgets-> GTK-> Cairo-> X Toolkit-> X protocol. De toute évidence, c'est le protocole au milieu qui relie les choses, et puisque Linux prend également en charge les sockets UNIX, un transport entièrement interne pour les données, ces deux types de choses peuvent fonctionner sur une machine si vous le souhaitez.

X fait référence au protocole et à tout élément fondamental de l'architecture tel que le serveur X qui exécute l'affichage graphique, le périphérique de pointage et le clavier.

GTK et QT sont deux bibliothèques GUI à usage général qui prennent en charge les fenêtres, les boîtes de dialogue, les boutons, etc.

GNOME et KDE sont deux environnements de bureau qui gèrent les fenêtres du bureau graphique, fournissent des applets et des trucs utiles comme des barres de boutons. Ils permettent également à plusieurs applications de communiquer via le serveur X (périphérique X-terminal) même si les applications s'exécutent sur différents ordinateurs distants. Par exemple, le copier-coller est une forme de communication inter-applications. GNOME est construit sur GTK. KDE est construit sur QT. Et il est possible d'exécuter des applications GNOME sur un bureau KDE ou des applications KDE sur un bureau GNOME car elles fonctionnent toutes avec le même protocole X sous-jacent.

C'est son organisation, vous en apprendrez plus sur cette image qu'à partir de plusieurs pages de texte:

Linux sur le bureau et certains serveurs sont toujours tous des graphiques de tampon X et de trame. Sous X window - Il s'agit de GTK + et Qt, OUI LES DEUX utilisent le système X, là encore il y a beaucoup d'environnements de bureau - Gnome, KDE utilise l'affichage X et leurs coques, etc.

Btw, il y avait une vidéo récente de linux conf (http://blip.tv/file/4693305/). Keith Packard d'Intel a parlé de X et GL * C'était intéressant.