La prise en charge des graphiques Linux a été une chose fortement mutante pendant la majeure partie de la vie du noyau. Initialement, le noyau ne parlait à la carte graphique qu'à des fins de mode texte. À l'époque, X utilisait ses pilotes pour tout faire, donc cela fonctionnait comme un énorme noyau en dehors du noyau.
Plus tard, avec Direct Rendering Infrastructure (DRI) , une partie du code des fonctionnalités graphiques accélérées a été déplacée côté noyau (appelé Direct Rendering Manager, DRM - rien à voir avec la gestion des droits numériques) pour fournir une interface cohérente et abstraite aux fonctionnalités d'accélération 3D.
Actuellement, vous n'avez pas besoin de charger un module DRM côté noyau. Mais si vous n'en avez pas, il est probable que votre session X retombera dans la 3D rendue par logiciel, ce qui est considérablement plus lent et plus gourmand en énergie que la 3D matérielle. Running glxinfo
affichera des informations à ce sujet.
Wayland est une histoire légèrement différente . Il se situe entre le noyau et les applications clientes. Avec Wayland, le serveur X est une autre application cliente, affichant sa fenêtre racine comme autre chose. Wayland se charge de parler au matériel (X parle à Wayland à la place). Étant donné que le projet est encore fortement en développement, il n'y a aucun moyen de savoir où il finira, mais d'après ce que je comprends, il a toujours besoin du support du noyau pour le rendu 3D.
Cela ressort également des diagrammes d'architecture Wayland: à gauche l'état actuel des choses pour un bureau X moderne, à droite le projet d'architecture Wayland. Le compositeur Wayland remplace le serveur X comme la chose qui parle au matériel, mais il ne remplace pas l' infrastructure du noyau - vous aurez donc toujours besoin d'un support approprié du noyau. En fait, étant donné les objectifs du projet, plus de choses devraient se déplacer vers le noyau pour une meilleure abstraction. Wayland, comme le serveur X, dépend toujours du matériel graphique.