Martin hat bereits eine Erklärung zu den Unterschieden zwischen X und Wayland verfasst und dabei auch erklärt, was das schlussendlich bedeutet. Im Grunde gelungen, fand ich mich danach doch nach weiteren Erklärungen suchen. Ich fasse hier zusammen, was - soweit ich es verstanden habe, das hier ist nicht mein Gebiet - nun der Unterschied zwischen X und Wayland ist. Dafür stelle ich beide Modelle gegenüber und freue mich über Korrekturen.
Auf der Waylandseite findet sich eine gute Erklärung der Architektur, mit Diagrammen, die ich hierfür mal übernehme.
XServer jetzt
Das ist im Grunde nicht zu kompliziert. Das Diagramm zeigt, wie auf ein Input-Event (z.B. ein Mausklick) reagiert wird. Der XServer wird von evdev benachrichtigt, danach benachrichtigt der XServer die Clients (also die registrierten Programme, die das Event betrifft, also z.B. das Fenster, auf das geklickt wurde), um dann - und das ist der zusätzliche Schritt um den es geht! - den Compositor zu benachrichtigen, damit über ihn die Oberfläche neu gezeichnet wird, der dann nochmal unnötigerweise den XServer benachrichtigt.
Beim Compositor wird anders als bei X eine Textur statt einer pixmap erstellt. Hier entstehen ggf. die Effekte, wie man sie durch Compiz kennt, und dabei wird die Grafikkarte genutzt. Ein Compositor muss nicht selbst ein Fenstermanager sein - Compiz und Metacity sind beides, xcompmgr ist nur ein Compositor. Daher kann letzterer auch mit normalen Fenstermanagern wie Fluxbox oder IceWM kombiniert werden, wobei inzwischen wohl eher diese Nicht-Compositoren als Fenstermanager die Ausnahme sind.
Metacity und Compiz sind die Fenstermanager und Compositoren, die von Ubuntu genutzt werden, Metacity für keine und einfache Effekte, Compiz wenn man die erweiterten aktiviert (zumindest war das so, ich hoffe, hier hat mich nicht die Enwicklung überholt).
Wayland dann
Wayland ersetzt den XServer bzw - wichtiger - vielmehr das zugehörige Protokoll (Wayland ist kein echter XServer, auch wenn das bei Golem so steht!) und ist gleichzeitig selbst ein Compositor. Das input-Event geht zum Wayland-Compositor, zu den Clients, von denen zurück zum Wayland-Compositor. Das spart den Schritt, nach der Kommunikation zwischen Clients und Server nochmal den Compositor zwischenzuschalten.
Das muss so zwar nicht sein - aber es wäre denkbar, dass tatsächlich eine Art WaylandServer Standard wird, der dann von den Compositoren genutzt wird - oder dass die dessen Compositor ersetzen. Nach dieser Option sieht es derzeit aus, also dass der Compositor des WaylandServers von z.B. Compiz ausgetauscht wird (Danke, Martin). Wichtig wird es demnach sein, zwischen dem Protokoll Wayland und der Software Wayland (was ich hier mit dem unzutreffenden Begriff WaylandServer versucht habe) zu unterscheiden.
Denkbar ist nämlich auch, zumindest so wie die Architektur momentan erklärt wird, dass es den großen zentralen Server für alle Clients so nicht mehr geben wird - immerhin könnte auch Firefox (so das Beispiel des Compiz-Entwicklers) zum Compositor werden und sich selbst zeichnen. Das wäre eine fundamentale Abkehr vom zentralen Client-Server-Modell, wie wir es derzeit haben.
Also, der Unterschied zwischen heute und morgen wäre: Ersetzung der Software XServer und des Protokolls X Window System (=X11) durch das Protokoll Wayland, wobei bei Wayland der Compositor sein eigener Server ist (wie das dann praktisch aussieht wird sich zeigen).
XServer dann
Interessant ist noch die Frage, wie der Umstieg zustande kommt. Wahrscheinlich wird lange dieses Bild bestimmend sein, und das wäre wohl eher schade:
Der XServer, der Wayland-Events bekommt statt direkt Input-Events, würde all die Anwendungen verwalten, die noch X- statt Wayland-Clients sind.
Mir ist allerdings nicht ganz klar, was alles umgeschrieben werden müsste, um dieses Szenario zu vermeiden. Sicher alle Fenstermanager, alle Toolkits (wie GTK); aber auch Anwendungen können derzeit direkt XLib benutzen. Ich habe das z.B. mal bei einem Musikplayer getan, um damit global Tastenkombinationen abzufangen und ihn so zu steuern. Wie aufwändig der Umstieg für die Linuxwelt als Ganzes wäre hinge demnach davon ab, wie verbreitet solche Verhaltensweisen sind und wie gut und einfach die Möglichkeiten, diese Wayland-kompatibel zu ersetzen.
