Pilote open source de carte graphique

Un pilote open source de carte graphique est un logiciel ou un ensemble de logiciels qui contrôle la carte graphique d'un ordinateur et prend en charge le rendu graphique de l'affichage, l'interface de programmations (dite API) et qui est livré avec une licence de type logiciel libre. Le pilote de carte graphique est écrit pour une gamme de matériel pour laquelle il est capable de gérer divers matériels (ou cartes) spécifiques. Il prend en charge en ensemble de sous-parties de l'API utilisé par les applications pour accéder à la carte graphique. Il fonctionne avec un système d'exploitation spécifique, et dans le cas de Linux, soit dans un noyau spécifique soit dans un Loadable Kernel Module.

Les données et instructions sont envoyées au GPU pour traitement. Les résultats rendus sont enregistrés dans un framebuffer, dont le contenu est scanné par le display controller et envoyé à l'écran.

Il permet aussi de contrôler la sortie sur l'affichage quand le display driver fait partie du matériel graphique. La plupart des pilotes en source ouvert de carte graphique sont développés par le projet Mesa. Le pilote est constitué d'un compilateur, une liste de rendering API, et du logiciel qui gère le matériel graphique.

Pilotes open source et binary drivers

Les pilotes sans code source libre et légalement gratuitement disponible sont appelés binary drivers, en langue anglaise. Les binary drivers utilisés dans le contexte d'un système d'exploitation en développement et soumis à modifications (comme Linux) créent des problèmes pour l'utilisateur final et la manutention des paquets. Ces problèmes qui affectent la stabilité, la sécurité et la performance du système, sont la principale raison pour le développement indépendant de pilote de carte graphique en source ouverte. En l'absence de documentation technique, une compréhension du matériel sous-jacent est souvent obtenue par clean-room reverse engineering. Sur la base de cette compréhension, un pilote de carte graphique en sources ouvertes peut être écrit et légalement publié et distribué sous une licence logicielle quelconque.

Dans de rare cas, un code source OEM est disponible sur Internet sans licence libre. Ceci permet l'étude du code et sa modification pour une utilisation personnelle, mais ni le code source altéré ni le code source d'origine ne peuvent être librement distribués. Les résolutions des bugs de pilote ne peuvent pas facilement être partagés sous le forme d'une version modifiée du pilote. Ceci réduit l'utilité de tels pilotes en comparaison de pilote open source de carte graphique.

Un inconvénient des drivers graphiques open source est que les évolutions du noyau Linux ou d'autres évolutions logicielles diverses peuvent conduire à des incompatibilité des drivers graphiques qui ne sont pas toujours supportés sur le long terme. Ainsi, dans les faits, les cartes graphiques utilisées avec des drivers en source ouverte sont confrontés à une obsolescence programmée.

[réf. souhaitée]

Dans l'écosystème des distributions de logiciel libre, un pilote binaire peut ne pas résister à une mise à niveau de la distribution de logiciels ce qui conduit à l'arrêt de fonctionnement de l'écran tant que le problème ne peut pas être résolu. Une des causes possibles de ce dysfonctionnement, dans le cas de Nvidia, tient à deux faits incompatibles:

• un pilote binaire est dépendant d'une version binaire du noyau du système d'exploitation;
• la mise à niveau d'une distribution peut conduire à un nouveau binaire du noyau du système d'exploitation remplaçant l'ancienne.

Support matériel

La suppression de firmware propriétaire présent dans le noyau Linux cause des pertes de fonctionnalités pour certains matériels qui n'ont pas d'équivalent open source. Cela affecte certaines cartes video telles que des cartes graphiques Nvidia. Lorsque c'est possible, un substitut libre au firmware est fourni. Ceci fait que Linux-libre, n'a pas toujours la meilleure prise en charge matérielle^{[réf. nécessaire]}.

Microcode

Linux-libre ne suggère pas la mise à jour de microcode de processeur, puisque ce code est propriétaire. Les mises à jour de microcode sont proposée dans la branche principale du noyau Linux entre autres raisons pour mitiger les vulnérabilités matérielles.

Histoire

Dans les débuts des PC, le fonctionnement des cartes VGA a été standardisé, notamment autour des différents modes d'affichages et du système d'interruptions logicielles, notamment sous DOS.

Dans les années 1986, sur les PC grands publics, en raison de la complexité d'écriture de drivers, Windows a apporté des drivers Windows génériques et encouragé les fabricants de matériel à les utiliser. Toutefois, ces drivers n'étant pas open source, il n'ont pas pu être réutilisés pour d'autres systèmes d'exploitation.

En 2009 et 2011, des drivers open sources sous Ubuntu supportent l'accélération matérielle 3D car Intel et ATI ont mis à disposition open source ces drivers. Par ailleurs, Linux dispose d'excellents graphiques 2D.

évolution des couches open source

Dans l'environnement Unix et Linux, de nouveaux drivers open-source sont apparus.

Principe initial du système X-Window

Pilotes 2D du serveur X

Les couches de logiciels et pilotes graphiques utilisées dans les distributions Linux ont évolué, à partir du protocole cœur du X Window System. Il s'agit à l'origine d'affichage de l'image des écrans en deux dimensions, dite 2D.

Cet affichage était optionnel puisque le lancement de X Window System dépend du Run level (comme expliqué plus bas). En principe, ceci assure que l'affichage fonctionne correctement en mode texte, sans défaut possible, avant le lancement du X Window System.

API GLX (1992-2012)

Rendu indirect sur GLX utilisant Utah GLX

L'API API GLX est une « Extension OpenGL pour le serveur X ». Elle est créée en 1992 et fournissant la connexion entre OpenGL et le serveur X : elle permet aux programmes qui souhaitent utiliser OpenGL de le faire dans une fenêtre fournie par le serveur X.

La dernière version est la version 1.4, sortie le 16 décembre 2005. Elle a été proposée à la déprécation en ce qui concerne X.org en 2012 par Ian Romanick en faveur d'EGL

---

Suite

---

• 
  Direct Rendering Infrastructure et framebuffer
• 
  tous les accès passent au travers du Direct Rendering Manager

---

Noyau Linux 3.12, depuis 2013

Dans le noyau Linux 3.12, les nœuds de rendu sont fusionnés et le mode setting est extrait à part. Wayland implémente le direct rendering sur EGL

.

L'interface de programmation (API) EGL fait le lien entre ses API de rendu et le système de fenêtrage du système d'exploitation sous-jacent. EGL est une option moins dépendante de la plate-forme que GLX ou WGL. Les spécifications d'EGL lui permettent de s'interfacer avec X11, avec une API très similaire à celle de GLX, la remplaçant ainsi avantageusement. EGL prend en charge la gestion des contextes graphiques, les relations entre les surfaces de dessin et les tampons mémoire, ainsi que la synchronisation du rendu. EGL permet ainsi la gestion efficace de rendu graphique mixte (2D et 3D) accéléré matériellement.

La bibliothèque logicielle libre Mesa, utilisée sous X.org, est compatible avec les versions 1.1 et 2.0 d'OpenGL ES.

Séquence de démarrage graphique Linux

Séquence initiale

Sous Linux, différentes classes de pilotes graphiques open source fonctionnent de manière très similaire. Le démarrage d'une distribution Linux pour PC, peut fonctionner sans recourir à aucun pilote spécifique à la puce graphique, car le gestionnaire de démarrage utilise des fonctionnélités génériques pour afficher des images, comme le Graphics Output Protocol (GOP) de l'UEFI, les pilotes d'extension du BIOS VESA (VBE) ou le mode texte VGA. Ce mode texte VGA est le même que celui qu'ilisait déjà le système DOS à la fin des années 1980.

Au travers des technologies VGA ou GOP le noyau affiche les premiers messages émis. Sur des systèmes modernes dotés de pilotes open source, le pilote graphique peut déjà être chargé en mémoire à partir du système de fichier initramfs chargé dès le démarrage du noyau, c'est-à-dire avant de pouvoir accéder au système de fichiers racine et donc avant tous les traitements suivants. Les distributions Linux modernes pratiquent généralement ce chargement précoce du pilote graphique du noyau depuis ce système de fichier initramfs. Ce module du noyau s'appelle i915 pour le matériel Intel. Il prend en charge l'initialisation du matériel, la gestion de la mémoire et la validation des commandes qui envoient les pilotes OpenGL ou vidéo à la puce graphique.

Au démarrage, le pilote du noyau définit une résolution supposée optimale pour l'écran de sortie. Cette résolution est déduite des informations obtenues à partir d'une structure de données appelée EDID (Extended Display Identifier Data), obtenue de l'écran au travers du PPC (ou DDC?) (Display Data Channel).

La définition des paramètres d'écran par le noyau est appelée paramètre de mode basé sur le noyau (KMS). Les pilotes graphiques du noyau sont donc parfois également appelés pilotes KMS. Cependant, le terme « pilote DRM » est plus approprié quand les pilotes et la fonction KMS appartiennent au Direct Rendering Manager (DRM) du noyau Linux. Ce pilote DRM est créé à la fin des années 1990, environ une décennie avant le KMS.

Séquence d'apparition

Lorsque le KMS définit la résolution de l'écran, l'écran s'assombrit brièvement et tous les messages émis jusqu'à ce point par le gestionnaire de démarrage ou le noyau disparaissent. Certaines distributions affichent une animation de démarrage à ce stade pour améliorer l'apparence de l'initialisation du système. Ceci est souvent pris en charge par le programme « Plymouth », qui utilise KMS, qui propose des fonctions de sortie d'images.

A ce stade, les capacités disponibles ne suffisent pas aux interfaces de bureau et aux programmes graphiques. Pour cette raison, le serveur X de X.Org démarre après l'initialisation de base du système. Il implémente le système X-Window (X11) et propose des fonctions et des interfaces avec lesquelles les applications peuvent créer une interface utilisateur et la transférer vers le serveur X. Il prend en charge la sortie via le matériel graphique et transmet les entrées, notamment souris et clavier, aux applications.

Précisions sur les pilotes de X-Windows

Les distributions Linux ont toujours utilisé un serveur X sur PC comme base pour les interfaces utilisateur graphiques. La configuration X auparavant requise et souvent fastidieuse est désormais pratiquement inutile, car les serveurs X modernes chargent automatiquement tous les pilotes requis pour les périphériques d'entrée et le matériel graphique lors de leur démarrage. Sur Intel, il s'agit du pilote X intel_drv.so, qui sur Ubuntu se trouve dans le répertoire xorg/modules/drivers/ sous /usr/lib ; sur un Fedora x86-64, le répertoire se trouve dans /usr/lib64/.

A l'origine, les pilotes X couramment utilisés sur les PC contenaient tout le nécessaire pour définir la résolution de l'écran. De nos jours, ce n'est plus le cas: Ils ne contrôlent plus ce paramètre de mode utilisateur. Au lieu de cela, ils doivent demander au pilote DRM via les fonctions KMS de configurer l'écran comme le spécifie l'utilisateur; par exemple via les paramètres d'affichage des bureaux ou l'outil de ligne de commande xrandr, qui transmettent leurs souhaits au serveur X et aux pilotes via l'extension X Resize, Rotate and Reflect (RandR).

Le pilote X est également responsable de l'accélération vidéo via l'extension X Video (XVideo ou XV en abrégé) et la compensation de mouvement X-Video (XvMC). Cependant, ces deux fonctions sont rarement utilisées car elles ne sont pas adaptées aux formats vidéo HD modernes.

La fonction principale restante du pilote X est l'accélération 2D, grâce à laquelle le pilote délègue le mouvement du contenu de la fenêtre à la puce graphique. Ces dernières années, EXA (mais UXA chez Intel) a été principalement utilisé à cette fin. Glamour, utilisé depuis un certain temps par le pilote Radeon X, est plus récent et utilise le pilote 3D pour l'accélération 2D.

Cette approche prive les pilotes X de leur dernière tâche essentielle. Elle facilite la conception de pilotes spécifiques au matériel et peut même les rendre inutiles. Elle attire ainsi d'autres développeurs.

En juillet 2014, dans ce contexte, Glamour a été intégré à X-Server version 1.16.

Architecture logicielle

Mesa (DRI) and Gallium3D have different driver models, but they share free and open-source code.

An example matrix of the Gallium3D driver model. With the introduction of the Gallium3D tracker and WinSys interfaces, 18 modules are required instead of 36. Each WinSys module can work with each Gallium3D device driver module and each State Tracker module.

Un pilote open source de carte graphique est principalement développé pour des distributions Linux et fonctionnent sur des noyaux Linux. Ils sont développés par des tiers développeurs enthousiastes et des employés de sociétés comme Advanced Micro Devices. chaque pilote est composé de cinq parties:

1. Un composant DRM dans le noyau Linux
2. Un composant KMS driver (pour Kernel Mode Setting) dans le noyau Linux (le display controller driver)
3. Un composant libDRM dans l'espace utilisateur (c'est-à-dire en dehors de l'espace du noyau) (une bibliothèque wrapper pour les appels système au DRM, qui ne devrait être utilisé que par Mesa 3D)
4. Un composant Mesa 3D dans l'espace utilisateur (c'est-à-dire en dehors de l'espace du noyau). Ce composant est spécifique au matériel; il est exécuté sur le CPU et traduit les commandes OpenGL, par exemple, en un code machine pour le GPU. En raison de la séparation du pilote de périphérique, le marshalling est possible. Mesa 3D est la seule implémentation libre d'OpenGL, OpenGL ES, OpenVG, GLX, EGL et OpenCL. En juillet 2014, la plupart des composants se conforment aux spécifications techniques de Gallium3D. Un State Tracker fonctionnel pour Direct3D version 9 est écrit en langage C, et un trackeur (non maintenu) pour les versions 10 et 11 de Direct3D est écrit en C++. Wine inclue un Direct3D version 9. Un autre composant de Wine traduit les appels Direct3D en appels OpenGL, fonctionnant avec OpenGL.
5. Device Dependent X (DDX), un autre pilote de carte graphique 2D pour serveur X.Org

Le DRM est spécifique au noyau. Un pilote VESA est généralement disponible pour tous les systèmes d'exploitation. Le pilote VESA suporte la plupart des cartes graphiques sans accélération et à des résolutions d'affichage limitées à un ensemble défini dans le BIOS vidéo par le fabricant.

Modules du noyau linux

Le noyau Linux est un exécutable doté de greffons dénommés modules, ou ko (pour l'anglais kernel object, et non pour le sens usuel): le noyau et ses options fonctionnent dès le démarrage du système Linux quand les modules sont chargés dynamiquement à la demande, c'est-à-dire au besoin. Il est possible de passer des options au noyau ainsi qu'aux modules.

Le noyau gère plutôt ce qui est commun à tous les drivers, comme l'option nomodeset, quand les modules gèrent plutôt ce qui est spécifique à une famille de matériel.

Les modules Linux pour les cartes graphiques portent des noms courts comme: amd, ast, bochs, gma500, i2c, i915, mgag200, nouveau, qxl, radeon, scheduler, tiny, ttm, udl, vboxvideo, vgem, virtio, vmwgfx, xen.

Certains modules sont soumis à l'intervention d'un plus grand nombre de contributeurs que d'autres. Par exemple, un échantillonnage sur une période de trois mois, montre que sur 169 auteurs, 55 contributeurs sont intervenus sur un pilote i915 et 44 sur un pilote amd, quand moins d'auteurs sont intervenus sur d'autres pilotes. Un auteur, Adam Tornhill, suggère que ce genre de métrique peut être lié à un besoin de coordination, voir à une estimation du risque de bogues.

Modules drivers du serveur X

Le démarrage du serveur X, sur les systèmes de la famille de Linux, n'est généralement pas lancé dès le début. L'organisation héritée de UNIX System V, utilisée par Solaris et plusieurs distributions Linux, lancement des applications suivant le numéro de leur Run level qui correspond au niveau de services activés et qui peut permettre de lancer le système avec ou sans certains services. Le serveur X est généralement lancé en mode multi-utilisateurs, c'est-à-dire pas avant le Run level 3. Le serveur X dispose souvent d'un Run level qui lui est quasiment dédié, comme le Run level 4 sur Slackware ou le Run level 5 sur d'autres distributions Linux.

Les modules du serveur X pour les cartes graphiques sont des bibliothèques partagées. Leur nom est court et se termine par drv. Les modules génériques portent le nom de fbdev ou de vesa. Ces modules génériques permettent de faire fonctionner divers matériels mais n'offrent pas les performances optimales qu'un module spécifique peut apporter lorsqu'il fonctionne. C'est aussi le cas du modules modesetting.

Les modules nv, nouveau et nvidia correspondent à du matériel vidéo de marque Nvidia.

Les modules ati et fglrx correspondent à du matériel vidéo de marque AMD/ATI.

Le module intel correspond à du matériel vidéo de marque Intel.

D'autres modules portent les noms de amdgpu, qxl, radeon, ou vmware.

Interactions avec le BIOS

Les cartes graphiques et leurs pilotes peuvent être en interaction avec le BIOS, notamment sur des sujets techniques tels que:

• un nouveau protocole graphique (Graphics Output Protocol ou GOP) pour configurer les modes graphiques ;
• extensions PCI (ou PCI Expansion ROM en anglais): micrologiciels exécutables, fournis par les périphériques PCI et exécutés par le BIOS pendant la phase de démarrage (Power On Self-Test ou POST) notamment pour initialisation du BIOS de la carte graphique. Le micrologiciel est présent en mémoire Flash ou dans le BIOS;
• les ordinateurs portables présentent également des spécificités car ils ne sont pas prévus pour un changement de carte graphique ;

Des spécifications ACPI récentes (version 5.0) permettent de nouvelles interactions des cartes graphiques avec le BIOS: comme l'installation de tables ACPI pendant la phase de démarrage pour donner au système d'exploitation des pointeurs vers des ressources dans la table BGRT (Boot Graphics Resource Table), comme un splash screen (écran de démarrage en Français) présenté à des fins cosmétiques par le micrologiciel.

Mode-setting

Le Kernel-based mode-setting, ou KMS, est un procédé permettant la gestion des modes d'affichage par le noyau Linux et celui des systèmes BSD. Il s'oppose à l'UMS (user mode setting).

Paramétrage et fonctionnalités spécifiques

Les pilotes de cartes graphiques à utiliser peuvent être paramétrés dans le fichier de configuration de X. Par exemple, un pilote Nvidia peut disposer d'options NoLogo, DPI ou RenderAccel, quand un pilote ATI peut disposer d'options TexturedVideo, Textured2D ou BackingStore.

Hors X

En dehors du sysème X-Window, d'autres bibliothèques permettent d'utiliser de pilote de l'interface graphique, comme DirectFB ou SDL.

Par fabricant

Pour profiter des fonctionnalité d’accélération matérielles de certaines cartes, des pilotes spécifiques existent. Toutefois, en l'absence de ces pilotes spécifiques, des pilotes VESA sont compatibles avec toutes les cartes compatibles VESA en particulier avec les cartes compatibles VBE 2.0 et à l'exception des processeurs ARM qui ont des cartes graphiques spécifiques. Toutefois, des pilotes de framebuffer existent en dehors de vesafb, comme le pilote de framebuffer mxvfb et intelfb. Ces pilotes de framebuffer gèrent une zone vue comme de la RAM par l'ordinateur, et permet de s'interfacer avec le mode setting, la mémoire de la carte, et l'accélération 2D dite scrolling (ou défilement en Français).

ATI and AMD

Radeon

Linux device drivers for AMD hardware in August 2016

Une carte graphique ATI Radeon HD 4770, basée sur le processeur graphique RV740.

Le spilotes propriétaires AMD's, AMD Catalyst pour leur Radeon, est disponible pour Microsoft Windows et Linux (anciennement fglrx). Une version actuelle peut être téléchargées sur le site d'AMD, et certaines distributions Linux le contiennent dans leurs dépôts. C'est en cours de remplcament avec un pilote hybride AMDGPU-PRO combiannt le noyau open-source, X et Mesa multimedia drivers avec du code fermé OpenGL, OpenCL et Vulkan drivers dérivés de Catalyst.

Les pilotes libres et en source ouverte (FOSS) pour les GPUs ATI-AMD sotnt en cours de développement suos l'appelation Radeon (xf86-video-ati ou xserver-xorg-video-radeon). Ils doivent encore télécharger du microcode propriétaire dans le GPU pour permettre l'accélération matérielle.Modèle:Failed verification

Le code Radeon 3D est séparé en trois pilotes, suivan la technologie du GPU: les pilotes classiques radeon, r200 et r300 et les pilotes Gallium3D r300g, r600g and radeonsi :

• Radeon prend en charge les séries R100.
• R200 prend en charge les séries R200.
• R300g prend en charge les microarchitectures antérieures à l'unified shader model: R300, R400 et R500.
• R600g prend en charge tous les GPUs basés sur TeraScale (VLIW5/4): R600, R700, HD 5000 (Evergreen) et HD 6000 (Northern Islands).
• Radeonsi supports tous les GPUs basés sur Graphics Core Next: HD 7000, HD 8000 et Rx 200 (Southern Islands, Sea Islands et Volcanic Islands).

Une matrice mise à jour est disponible, et une prise en charge existe pour le Video Coding Engine et Unified Video Decoder. Les pilotes FOSS Radeon graphics ne sont pas construits par reverse-ingénierie, mais sont basés sur la documentation releasé par AMD sans imposer de non-disclosure agreement (NDA). Le documentation commença à être graduellement releasée en 2007.

En addition de la fourniture de la documentation nécéssaire, des employés d'AMD ont contribué à la prise en charge du matériel et des fonctionnalités de leur société.

Tous les composants des pilotes des cartes graphiques Radeon sont développés par des contributeurs cœrs et les partie prenantes intéressées mondialement. En 2011, les r300g dépassent Catalyst dans certains cas.

AMDGPU

En 2014 Game Developers Conference, AMD annonce l'exploration d'une stratégie pour re-fonder la partie user-space de Catalyst sur un module noyau DRM libre plutôt que leur blob noyau propriétaire.

La publication de la pile et du module noyau AMDGPU nouveau est annoncé sur la mailing list dite dri-devel en Avril 2015. quand AMDGPU ne prend en charge officiellement que les cartes graphiques GCN 1.2 et suivantes, une prise en charge expérimentale pour les cartes graphiques GCN 1.0 and 1.1 (prise en charge officielle seulement par le pilote Radeon) peut être activée au travers d'un paramètre dunoyau. Un libdrm distinct, libdrm-amdgpu, est inclu depuis libdrm 2.4.63.

La code radeonsi 3D mentionné dans le paragraphe Radeon précédent (ou antérieur) est aussi utilisé dans amdgpu; le pilote 3D driver s'interface par derrière à la fois avec radeon et amdgpu.

Intel

Vue du dessus d'un Intel Core i7 Sandy Bridge, modèle 2600K, production vers 2011-2013)

A son actif, Intel est connu pour avoir produit (or commissioning) des pilotes open-source pour ses puces graphiques, à l'exception de leur puce PowerVR-based. Leur pilote 2D X.Org est appellé xf86-video-intel. Le pilote mode-setting du noyau dans le noyau Linux n'utilise pas le BIOS vidéo pour basculer les modes vidéos; puisque certains BIOS ont des plages de mode limitées, ceci apporte un accès plus large à ceux pris en charge par les adaptateurs vidéo Intel.

La société a travaillé à optimiser leurs pilotes Linux pour la performance approchant leur contrepartie Windows spécialement sur Sandy Bridge et les matériels plus récents où les optimisations de performance ont permis aux pilotes d'Intel de surpasser leurs pilotes propriétaires Windows dans certaines tâches, en 2011 Some of the performance enhancements may also benefit users of older hardware.

La prise en charge des caches de base niveau d'Intel (Last Level Cache, L4-Cache, Crystalwell and Iris Pro) a été ajoutée dans le noyau Linux 3.12. En 2013, la société emploie 20 à 30 développeurs Linux à plein temps.

Autres

D'autres pilotes opens sources sont disponibles pour d'autres cartes : Matrox, S3 Graphics, Arm Ltd, Imagination Technologies, Qualcomm et Broadcom par exemples.

Autres cartes

Red hat est l'une des sociétés intéressée par le développement de pilotes graphiques pour systèmes open source

Même si Silicon Integrated Systems et VIA Technologies ont exprimé un intérêt limité dans les pilotes FOSS, les deux ont publié du code source qui a été intégré dans le serveur X.Org par des développeurs FOSS. En juilet 2008, VIA a ouvert la documentation de leurs produits pour améliorer son image dans les communautés Linux et open-source. La société a échoué à travailler avec la communauté open-source pour fournir la documentation et un pilote DRM fonctionnel, abandonnant les attentes d'une prise en charge Linux. Le 6 janvier 2011, il a été annoncé que VIA n'est plus intéressé par les initiatives de prise en charge open source.

La société DisplayLink a annoncé un projet open-source, Libdlo, avec le but de porter la prise en charge de leur technologie USB graphics sur Linux et d'autres plateformes. Ce code est disponible sous licence LGPL, mais il n'a pas été intégré dans un pilote X.Org. La prise en charge de DisplayLink graphics est disponible au travers du pilote "udlfb" du noyau (avec fbdev) en mainline et le pilote udl/drm, qui en mars 2012 n'était disponible qua dans l'arborescence drm-next.

Dans vendeur sans lien avec le matériel peuvent aussi assister les initiatives des graphiques libres. Red Hat emploie deux personnes à plein temps (David Airlie et Jérôme Glisse) pour travailler sur le logiciel Radeon, et le projet Fedora Project parraine un événement Fedora Graphics Test Week avant le lancement des nouvelles versions de leur distribution Linux pour essayer des pilotes graphiques libres. D'autres sociétés ont fourni du développement ou du supporty compris Novell et VMware.

Identification

Le système peut savoir le pilote à utiliser car un système de configuration existe. La configuration est dite manuelle quand l'utilisateur doit paramétrer le pilote de carte graphique ou automatique quand des mécanismes d'auto-détection sont utilisés. Un des mécanismes d'auto-détection existant communique au travers du bus PCI un numéro 16 bits qui identifie la carte dans la matrice du site web du fabricant de la carte.

Dans l'environnement Xorg, un utilitaire existe pour reconnaître le type de carte graphique et en déduire un fichier de configuration Xorg. Le fichier généré peut être modifié manuellement mais cette tâche est complexe.

Problème connu

Les fournisseurs peuvent fournir soit des pilotes graphiques qui privilégient la compatibilité soit des pilotes graphiques qui privilégient la performance suivant les besoins de l'utilisateur.

Un problème connu est la présence d'écrans noirs dus à une certaine incompatibilité de certains pilotes avec l'UEFI.

« Video problems are especially tricky because it is hard to fix computer when the display is not working. »

— Keith Curtis, page 213

Voir aussi

• Nouveau (informatique)
• radeon (logiciel)
• DirectFB

Notes et références

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Free and open-source graphics device driver » (voir la liste des auteurs).