Das Design von XFree86 bei den Versionen 1 bis 3 ist extrem SVGA-zentrisch. Das bringt viele versteckte Abhängigkeiten mit sich, welche nicht ganz offensichtlich für den Entwickler sind.
Es erfordert für die Treiberentwicklung ein hohes Maß an Programmieraufwand, um die Lauffähigkeit eines X-Servers mit neuen Treibern zu erreichen.
Aktuelle Features wie hardwarebeschleunigte 3D-Grafik oder Multi-Monitor-Betrieb ließen sich basierend auf dem alten Design des X-Servers kaum realisieren.
Ebenfalls besteht das XFree86 der Versionen 1 bis 3 aus einem monolithischen Design, was so viel bedeutet, dass der X-Server aus einem einzigen großen Stück Software besteht.
Dieses Design führte zu großen und unhandlichen Server-Binaries. Das bedeutet, dass beispielsweise jeder X-Server den Framebuffer-Code für alle Farbtiefen oder alle unterstützten Font-Renderer enthält.
Dadurch entstand der negative Effekt, dass bei neuen Treibern die Entwickler einen komplett neuen X-Server zur Verfügung stellen mussten, obwohl 90% des Codes sich nicht geändert hatte.
Durch die vielen verschiedenen X-Server unter XFree86 3.x ( z.B. XF86_SVGA, XF86_S3, ...) ist eine genaue und ausführliche Dokumentation des Designs sehr gering.
Ein grundlegender Unterschied zum bisherigen X11 auf der Basis von XFree86 3.x ist, dass jetzt ein modularisiertes Konzept zu Grunde liegt. Es wird jetzt streng getrennt, zwischen dem eigentlichen X-Server und den ladbaren Modulen ähnlich dem Prinzip des Linux-Kernels.
Es muss nur noch der X-Server an das jeweilige Betriebssystem angepasst werden. Daneben existieren die Module, welche die notwendigen Anpassungen an die Grafikkarte beziehungsweise den Grafikchip enthalten, unabhängig vom einheitlichen X-Server.
Auf diese Weise wird die Weiterentwicklung von Treibern erheblich beschleunigt, weil jede Änderung nur am betroffenen Modul erfolgen muss, und nicht mehr z.B. den gesamten sehr umfangreichen SVGA-Server betrifft. Sogar das Bereitstellen von Modulen in Form von Binaries durch kommerzielle Hersteller, welche die Spezifikationen nicht freigeben möchten, ist jetzt möglich. Zum Laden des passenden Driver-Modules sind die Konfigurationsdatei: /etc/X11/XF86Config notwendig wie z.B.
Section „DEVICE“
BoardName "MAG G400"
BusIDd "1:0:0"
Driver "mga"
Identifier "Device[0]"
VendorName "Matrox"
Videoram "32768"
Wie bereits erwähnt verfügt XFree86 4.x über eine modulare Architektur, die es sogar erlaubt zur Laufzeit des X-Servers Module nachzuladen, wie die Abbildung unten verdeutlicht. Derzeit wird aber dieses Feature fast ausschließlich zur Startzeit vom X-Server benutzt.
Nach dem Abarbeiten von Kommandozeilenparametern und Konfigurationsdatei lädt der X-Server die benötigte Programmtiefe zur Laufzeit nach.
Dabei benutzt XFree86 einen plattformunabhängigen Loader, welcher in der Lage ist beliebige Objektdateien zu laden, mit Hilfe von XFree86 - eigenen Routinen.
In der Praxis sieht das folgendermaßen aus. Der Server öffnet die Objekt-Datei und wertet die verschiedenen Sektionen aus, gemäß des erkannten Dateiformats. Dann mappt der X-Server den ausführbaren Code dieser Datei in seinen Speicherbereich und macht sich ihn damit verfügbar.
Erforderlich dazu ist es, die innerhalb des Modules verwendeten symbolischen Adressen entsprechend aufzulösen (zu relozieren). Alle vom Modul exportierten globalen Symbole werden innerhalb des Loaders aufgelöst und in Symboltabellen eingetragen. Die im Modul referenzierten Symbole werden entsprechend der Symboltabellen im Loader reloziert.
Für echte Portabilität der Module dürfen diese nur Symbole in anderen Modulen referenzieren oder Symbole, die der Server explizit exportiert. Direkte Referenzen auf die C-Bibliothek sind untersagt. Stattdessen bietet XFree86 eine eigene Sammlung von ANCI-C-Wrappern.
Welche Module der Server lädt, bestimmen im Server-Binary fest eingestellte Defaults, Angaben in der XF86Config-Datei oder Abhängigkeiten unter den verschiedenen Modulen. Die abschließende Relozierung aller Module findet erst nach ihrem Laden statt.
Bei XFree86 4.x gibt es auch noch diverse Nachteile. Unter anderem werden zur Zeit durch XFree86 4.x noch nicht so viele Grafikkarten unterstützt, wie durch das bisherige XFree86 3.x. Auch die Unterstützung für ältere Grafikkarten wird es fast überhaupt nicht mehr geben.
Ein weiteres Problem gibt es für die Entwickler von Treibern, nämlich das der Fehlersuche. Es existiert kein optimal angepasster Debugger.
Weitere potenzielle Probleme ergeben sich aus den Security-Überlegungen. Der X-Server läuft unter Linux mit Super-User-Privilegien und dies gilt auch für den Code aus Modulen, die er nachlädt. Daher ist Vorsicht geboten bei der Installation von Modulen gegenüber unbekannter Quellen.
Ein eher ideologisches Problem ergibt sich aus der Frage der Open-Source-Bewegung. Die Möglichkeit für Hersteller von Grafikkarten, Treiber-Binaries zu erstellen und diese mit ihren Karten zu vertreiben, ist auf der einen Seite ein großer Schritt in Richtung der besseren Hardwareunterstützung von XFree86. Auf der anderen Seite könnte dies aber den Anreiz für Hersteller senken, Dokumentationen zu ihren Chipsets und Sourcen zu den Treibern zu veröffentlichen.