Thema: X11 / X.Org Server / Wayland ...

[ritschibie]

Wayland mit einfachen GTK-Anwendungen
(Bild: Wayland)

Der Displayserver Wayland und der Compositor Weston sind ab sofort in den Quellen von Ubuntu 12.04 verfügbar. GTK-Anwendungen können Wayland jedoch nicht nutzen, GTK müsste dazu neu kompiliert werden.

Nach dem Displayserver Wayland 0.85 ist nun auch der dazugehörige Compositor Weston 0.85 in den Quellen des kommenden Ubuntu 12.04 zu finden. Diese ersten offiziellen Testversionen von Wayland und Weston sind im Februar 2011 erschienen und sollen vor allem dazu dienen, die APIs und die Protokollimplementierungen zu stabilisieren.

Wayland und Weston funktionieren seit der Veröffentlichung der Version 0.85 auch mit externen Projekten wie Mesa oder dem KMS-Stack des Linux-Kernels, ohne dass diese speziell angepasst werden müssten. Das gilt jedoch nicht für die GTK-Pakete in Ubuntu 12.04 alias Precise Pangolin. Dies führt dazu, dass GTK-Anwendungen in Ubuntu 12.04 nicht zusammen mit dem Displayserver verwendet werden können.

Der Grund für die Inkompatibilität ist der "Feature Freeze" im Entwicklungszyklus von Ubuntu 12.04. Das heißt, seit etwa einem Monat dürfen keine neuen Funktionen, Pakete oder APIs zu Precise Pangolin hinzugefügt werden, die Entwickler konzentrieren sich auf das Beheben von Fehlern. Um Wayland und Westen mit GTK verwenden zu können, müsste dieses aber mit der Option "--enable-wayland-backend" neu gebaut werden. Das lehnt das Ubuntu-Team derzeit jedoch noch ab. In einem Bug-Report wird diese Funktion jedoch gefordert.

Ob und wann Wayland problemlos in Ubuntu getestet werden kann, steht noch nicht fest. Auch nicht, wann Wayland standardmäßig den X-Server in Ubuntu ersetzen wird, was der Ubuntu-Gründer Mark Shuttleworth bereits als langfristiges Ziel angekündigt hat. Gleiches gilt für das Fedora-Projekt. Es ist jedoch wahrscheinlich, dass Wayland und Weston zusammen mit GTK 3.4 im kommenden Fedora 17 getestet werden können.

Quelle: www.golem.de

[SiLæncer]

Die Entwickler von X.org haben den ersten Veröffentlichungskandidaten von X.org 7.7 mit Multitouch-Unterstützung und vielen anderen Verbesserungen bereitgestellt.

Sechzehn Monate Nach X.org 7.6 wachsen damit die Hoffnungen auf eine baldige Freigabe der offiziellen Version 7.7. Das Team plant der Ankündigung zufolge, in der aktuellen Testphase nur noch Korrekturen, Updates der Dokumentation und Bereinigungen zuzulassen. Außerdem wird noch auf die finale Version einiger Komponenten gewartet. Doch es sollte nun nicht mehr allzu lange dauern, bis die Version 7.7 erscheint.

Eine der größten Neuerungen in X.org 7.7 ist die umfassende Behandlung von Multitouch-Events. Außerdem erhalten Anwendungen die Möglichkeit, die rohen Events von den Eingabegeräten zu verfolgen, um eine spezielle Bearbeitung vorzunehmen. Scroll-Events enthalten mehr Detailinformationen, womit sich ein stufenloseres Scrollen besser verwirklichen lässt.

Es gibt nun sogenannte Fence-Objekte in der Synchronisationserweiterung. Sie dienen zum Synchronisieren der Bildschirmausgabe eines Programmes mit anderen Aktionen. Sogenannte Zeigerbarrieren ermöglichen es Anwendungen, die Bewegung des Mauszeigers auf bestimmte Weise einzuschränken. Diese Neuerung soll vor allem auch auf Systemen mit mehreren Bildschirmen ein für die Anwendungen logischeres Verhalten ermöglichen.

X-Ressourcen können nun besser abgefragt werden, was auch Informationen über die Größe enthält. Bei den XCB-Bibliotheken wurde begonnen, Unterstützung für GLX und XKB einzubauen. Diese Arbeit ist noch nicht abgeschlossen. Auch die Dokumentation wurde wesentlich erneuert. Die Umstellung auf DocBook XML wurde abgeschlossen. Es können jetzt Querverweise zwischen den einzelnen Dokumenten gesetzt werden. Die Dokumentation ist auch online zu lesen.

Weitere Änderungen der neuen Version betreffen die zahlreichen Erweiterungen und Verbesserungen der Treiber sowie Korrekturen. Einzelheiten sind in den Hinweisen zur Veröffentlichung zu finden.

Seit Version 7.0 von X.org ist die freie X11-Implementierung modular aufgebaut und lässt sich mit Hilfe der GNU Autotools compilieren. Sie besteht aus einer Anzahl von unabhängigen Modulen, die von den Entwicklern separat gepflegt und weiterentwickelt werden. Die neue Version kann im Quellcode vom Server des Projekts oder einem der zahlreichen Spiegel-Server heruntergeladen werden.

Quelle : www.pro-linux.de

[SiLæncer]

Durch die Einbindung eines neuen Treiber-APIs in X.org soll der freie X-Server besser mit modernen Desktop-Treibern unter Windows konkurrieren können und weitere fortgeschrittene Funktionen erlauben. Erste Patches sind bereits veröffentlicht. Der Zeitpunkt einer Freigabe steht allerdings noch nicht fest.

Betrachtet man die Struktur des X.org-Servers, so stellt sich recht schnell heraus, dass er aus zwei Basiskomponenten besteht. Zum einen enthält er eine hardwarenahe Schicht unter dem namen DDX (Device Dependent X) der alle gerätespezifischen Funktionen umfasst und unter hw/xfree86 zu finden ist, und einer gäreteunabhängigen Schicht unter dem Namen DIX (Device Independent X). Die Kommunikation zwischen den Schichten erfolgt durch ein definiertes API, das unter anderem aus zwei separaten Strukturen besteht: screenInfo.screens in DIX und xf86Screens in DDX.

Wie Dave Airlie nun in seinem Blog schreibt, stellt die Trennung der Strukturen mittlerweile ein gewichtiges Problem dar, das unter anderem die Einbindung moderner Funktionen unter X.org verhindert. Airlie selbst arbeitet bereits seit geraumer Zeit an diversen Funktionen für X.org. Unter anderem plant er, USB-Hotplug-Unterstützung und GPU-Offloading einzubauen. Bei GPU-Offloading, das Airlie PRIME getauft hat, handelt es sich um einen Mechanismus, der dem Server erlauben soll, von einer GPU berechnete Objekte auf dem Ausgabemedium einer anderen GPU darzustellen. Zudem plant der Entwickler, in X.org eine neue Funktionalität einzubinden, die dem Server ermöglichen soll, aktive X.org-Sessions zwischen verschiedenen Treibern und GPUs zu schalten.

Um das Vorhaben realisieren zu können, bedarf es allerdings diverser Änderungen an der Struktur des Servers, denn die Limitierung der Server-APIs stellt laut Airlie das größte Hindernis für eine erfolgreiche Implementierung dar. Zwar ging die ursprüngliche Idee davon aus, das Treiber-API des Servers unberührt zu lassen und beispielsweise USB-Hotplug auf Basis von Xinerama zu realisieren, doch erwies sich das Vorhaben in der Praxis als nicht durchführbar. Einzig die Implementierung einer Schicht zwischen den diversen Server- und Treiber-Objekten versprach bessere Resultate. Die Negativseite des Vorhabens waren allerdings massive Codeduplizierungen.

Um auch dieses Problem zu lösen, schlug Airlie deshalb, vor die APIs komplett zu ändern. Ziel der Änderung ist es, sowohl xf86Screens als auch screenInfo aus dem Server zu entfernen und durch besser skalierbare Strukturen zu ersetzen. Die ersten Patches sind bereits auf der Liste des Projektes eingegangen und sollen als Demonstration der künftigen Struktur dienen. Weitere Änderungen sind bereits in der Warteschleife und sollen an die Liste übermittelt werden, sobald die neue Struktur von den anderen Entwicklern abgesegnet wurde.

Die Änderung des Treiber-APIs stellt einen massiven Eingriff in die Struktur des Servers dar. Denn neben der eigentlichen Änderungen am Kern führt sie zwangsläufig auch dazu, dass alle Treiber des Servers angepasst werden müssen. Zwar verspricht Airlie, die notwendigen Änderungen so gering wie möglich zu halten, um diverse Anpassungen wird allerdings kein Treiber herumkommen. Dementsprechend sollten auch die Erwartungen gedämpft werden, denn mit einer raschen Freigabe der neuen Funktionalität ist nicht zu rechnen.

Quelle : www.pro-linux.de

[SiLæncer]

Die Version 7.7 des X-Window-Systems der X.org Foundation enthält die bereits veröffentlichten Komponenten Xserver und Xinput mit Multitouch-Unterstützung. Zudem ist die Dokumentation nun einheitlich konvertiert.

In X11R7.7 der X.org Foundation sind alle seit Dezember 2010 für das X-Window-System veröffentlichten Komponenten enthalten. Dazu zählen unter anderem die X-Server-Versionen 1.10, 1.11 und 1.12. Letztere sorgt zusammen mit der Erweiterung Xinput 2.2 für die Unterstützung von Multitouch-Gesten. Diese Neuerung gilt nicht nur für Touchscreens, sondern auch für Touchpads.

Die XCB-Bibliotheken (X protocol C-language Binding) unterstützen nun auch teilweise die Erweiterungen GLX und XKB. Den Entwicklern zufolge ist diese Unterstützung jedoch noch nicht vollständig, auch seien nicht alle Funktionen über das XCB-API ansprechbar.

Mit der Veröffentlichung von Version 7.7 haben die Entwickler nun auch sämtliche Dokumentationen in das XML-basierte Docbook-Format konvertiert. Sämtliche Neuerungen aller Komponenten finden sich in den Release Notes und dem Changelog.

X11R7.7 läuft unter Linux, BSD, GNU Hurd, Solaris, Mac OS X und mit Cygwin auch unter Windows. Die Sammlung der verschiedenen Komponenten steht unter freizügigen Lizenzen zum Download zur Verfügung. Die meisten Linux-Distributionen liefern die jeweils aktuellen Bestandteile als Pakete statt der gesamten Softwaresammlung.

Quelle : www.golem.de

[ritschibie]

Der Entwickler Tiago Vignatti hat beschrieben, wie X11-Anwendungen unter Wayland laufen. Die Architektur soll dafür sorgen, dass es keine merklichen Geschwindigkeitseinbußen gibt.

X11 unter Wayland

Während viele Anwendungen in absehbarer Zeit nativ unter Wayland laufen werden, weil die zugrundeliegenden Toolkits - darunter Qt und GTK+ - auf Wayland portiert werden, wird es weiterhin viele native X-Anwendungen geben. Es ist den Entwicklern von Wayland entsprechend wichtig, diese Anwendungen ausführen zu können. Dafür wurde die Anpassungsschicht xwayland entwickelt.

Der Entwickler Tiago Vignatti beschreibt nun in seinem Blog, wie sich diese in Wayland einfügt. Die zentrale Komponente von Wayland ist der Compositor Weston. Native Wayland-Anwendungen (Clients) verbinden sich direkt mit Weston. Weston beherbergt jedoch neben dem Compositor und der Desktop-Shell auch das Modul xwayland.

xwayland ist kein X-Server, vielmehr öffnet es einen X-Socket und wartet dort auf Clients, die sich mit dem X-Server verbinden wollen. Sobald ein Client sich verbindet, startet xwayland einen X-Server. Der Client und alle weiteren startenden X-Clients werden an diesen Server weitergereicht. Der X-Server nutzt einen speziellen Wayland-Videotreiber und kommuniziert mit xwayland über ein eigenes Protokoll. Somit wird der X-Server nur gestartet, wenn er benötigt wird. Mit diesem Schema vermeiden die Entwickler den Overhead von X, wenn er nicht gebraucht wird, und beschleunigen den Start von Wayland.

Der Window-Manager wird nicht vom X-Server, sondern von Weston gestartet. Es handelt sich um einen speziellen Manager, der die Window-Manager-Protokolle EWMH und ICCCM auf Wayland abbildet. Dadurch sollen sich X11-Anwendungen nahtlos in den Desktop einfügen. Dieser Window-Manager sorgt wie die üblichen X-Window-Manager auch für die Rahmen und sonstige Dekoration der Fenster sowie für die Kommunikation der Clients untereinander, z.B. über die Zwischenablage und später auch über Drag und Drop.

Die Fenster der X11-Anwendungen werden nicht direkt auf den Bildschirm, sondern in Pufferspeicher gezeichnet. Dieser Puffer wird dann vom Compositor auf dem Bildschirm eingeblendet. Da dafür keine Protokollaufrufe nötig sind, soll kein nennenswerter Geschwindigkeitsverlust auftreten.

X11-Anwendungen müssen natürlich auch die Möglichkeit haben, Eingaben zu erhalten. Die hierfür benötigten Komponenten sind laut Vignatti bereits vorhanden. Wenn der X-Server gestartet wird, erzeugt Wayland Pseudo-Geräte, die vom X-Server für die Tastatur und die Maus genutzt werden können. Die Daten gelangen also über Wayland zu X. Es gibt, so Vignatti, noch offene Punkte bei den Zeiger-Einstellungen und der komplexen Logik des Input-Grabbing, bei der ein Client bestimmte Eingaben exklusiv für sich reklamiert. Ein kurzes Video demonstriert den aktuellen Stand von Wayland.

Quelle: www.pro-linux.de

[ritschibie]

In den Entwicklerzweig des X-Servers von X.org sind Änderungen eingeflossen, die die Unterstützung von zur Laufzeit aktivierbarer Grafikhardware bei Linux-Distributionen verbessern sollten. Die ist bei Linux bislang eher dürftig und war ein Anlass für das "Nvidia, fuck you!", mit dem Linux-Erfinder Linus Torvalds kürzlich viel Aufsehen erregt hat.

Nvidia hat zu der jetzt integrierten und in der heute veröffentlichten ersten Vorabversion des X-Servers 1.13 enthaltenen Infrastruktur offenbar nicht sonderlich beigetragen. Sie besteht aus mehreren Teilen; darunter Patches für "Output Slaves", durch die der X-Server zur Laufzeit erscheinende Grafikhardware aktivieren kann. Das ist etwa für DisplayLink-Hardware interessant, um eine schon gezeigte Desktop-Oberfläche direkt nach dem Anstecken eines USB-Monitors auf diesen zu erweitern, ohne den X-Server neu starten zu müssen.

Darauf baut die ebenfalls in den X-Server-Code integrierte Funktion "Offload Slaves" auf. Durch sie kann ein Treiber Grafikberechnungen an einen Grafikchip abtreten, um das berechnete Bild anschließend ohne viel Overhead selbst auszugeben. Das ist zur Unterstützung für Hybridgrafik in aktuelle Notebooks interessant, denn die zuschaltbaren GPUs (Graphics Processing Units) von AMD und Nvidia kümmern sich bei den zumeist nur um Grafikberechnungen; die eigentliche Bildschirmansteuerung und Bildausgabe erfolgt auch bei zugeschaltetem Grafikchip über die GPU im Prozessor.

Die neuen Funktionen lassen sich über eine Erweiterung des Protokolls RandR (Resize, Rotate and Reflect Extension) nutzen, das diese Fähigkeiten durch die Versionsbezeichnung 1.5 ausweist. Damit diese unter dem Begriff "Prime Infrastucture" entwickelten Verbesserungen es noch in den derzeit vorbereiteten und für Anfang September geplanten X-Server 1.13 schafften, hatte der X.org-Entwickler Keith Packard eigens das Ende der Phase, in der die größeren Änderungen für diese Version aufgenommen werden, um einige Tage bis zum gestrigen Montag ausgedehnt. Die Erweiterungen für den X-Server sind zudem auf Grundlagen im Linux-Kernel angewiesen, die das noch in diesem Monat erwartete Linux 3.5 bieten wird.

Maßgeblich entwickelt wurden die Prime-Infrastruktur für den Linux-Kernel und den X-Server von Red-Hat-Entwickler Dave Airlie. Er hat die Funktionen bereits in zwei You-Tube-Videos demonstriert, als sie noch in Entwicklung waren. Packard hat das Zuschalten eines DisplayLink-Monitors kürzlich ausprobiert und erläutert einige Erfahrungen und noch zu korrigierende Ungereimtheiten in einem Blog-Eintrag.

Abgeschlossen ist die Arbeit an ordentlicher Unterstützung für Hybridgrafik damit noch nicht, denn bei den jetzt aufgenommen Änderungen handelt es sich nur um die ersten beiden von vier Schritten, die Airlie vor einem Monat umrissen hatte; Funktionen zum kompletten Umschalten auf einen anderen Grafikchip zur Laufzeit und andere Erweiterungen, die vom X-Betriebsmodus Xinerama bekannte Funktionen ermöglichen sollen, stehen noch auf der ToDo-Liste. Es wird sich zudem zeigen müssen, wie gut die Infrastruktur in den Distributionen mit Kernel 3.5 und X-Server 1.13 arbeiten wird. Bislang ist nicht absehbar, ob die proprietären Linux-Grafiktreiber von AMD oder Nvidia die neue Infrastruktur nutzen werden; fürs Erste dürfte die trickreich, technisch aber etwas umständlicher als Prime vorgehende Software Bumblebee daher weiter die beste Möglichkeit sein, um die Leistungsfähigkeit von Nvidia-GPUs ins Notebooks mit Nvidias Optimus auszureizen.

Quelle: www.heise.de

[ritschibie]

Wayland 1.0, die erste stabile Version des mit Spannung erwarteten neuen Display-Servers, lässt weiter auf sich warten.
Die jetzt veröffentlichte Version 0.95 leitet eine neue Stabilisierungsphase ein.

Wayland ist ein Protokoll zwischen Compositor und Client-Applikationen sowie die entsprechende Implementation als C-Bibliothek. Der Compositor kann dabei ein eigenständiger Display-Server sein, wie der vom Projekt entwickelte Referenz-Compositor Weston, eine X-Anwendung oder ein Wayland-Client. Die Clients können traditionelle Anwendungen, X-Server oder andere Display-Server sein. Wayland und Weston bilden zusammen ein vollständiges Fenstersystem, das X in einigen Bereichen ablösen könnte. Details können der Architektur-Übersicht entnommen werden.

Während viele Anwendungen in absehbarer Zeit nativ unter Wayland laufen werden, weil die zugrundeliegenden Toolkits - darunter Qt und GTK+ - auf Wayland portiert werden, wird es weiterhin viele native X-Anwendungen geben. Wayland wird daher X11-Anwendungen über die Anpassungsschicht xwayland effizient ausführen können.

Kristian Høgsberg, der Initiator von Wayland, hat jetzt Version 0.95 von Wayland und Weston veröffentlicht. Es handelt sich um die zweite Testversion nach der im Februar vorgestellten Version 0.85, die für eine Weile stabil gehalten wurde. Nach Angaben von Høgsberg leitet diese Version eine neue Stabilisierungsphase ein. Das bestehende Protokoll und das Client-API werden in dieser Form bestehen bleiben. Zwar sind Änderungen bis zur Version noch nicht ganz ausgeschlossen, diese werden aber, wenn möglich, durch eine Änderung der Versionsnummer ausgedrückt. Inkompatible Änderungen sollen nur vorgenommen werden, wenn es absolut nötig ist. Sobald die Version 1.0 veröffentlicht wird, soll es keinerlei inkompatible Änderungen mehr geben.

Noch nicht endgültig sind die APIs des Wayland-Servers, das Protokoll zwischen Wayland und Weston sowie die Schnittstellen zu Mesa, die mit dem kommenden Mesa 8.1 eingefroren werden sollen.

Einzelheiten zu den Änderungen in Version 0.95 liegen nicht vor. Wayland und Weston können in der aktuellen Testversion als Quellcode von der Releases-Seite des Projekts heruntergeladen werden.

Quelle: www.pro-linux.de

[SiLæncer]

Der zur Wochenmitte von den X.org-Entwicklern freigegebene X-Server 1.13 bringt bessere Unterstützung für zur Laufzeit zuschaltbare Grafikhardware. Dazu zählen via USB angebundenen DisplayLink-Monitore sowie Hybridgrafiktechniken; zu solchen zählt Nvidias vor allem in Notebooks eingesetzte Optimus, bei der ein GeForce-Chip erst bei Bedarf zuschaltet und die von ihm berechnete Bilder über den Grafikkern des Prozessors ausgibt.

Zur Konfiguration von zur Laufzeit zuschaltbarer Grafikhardware haben die Entwickler beim X-Server 1.13 das Protokoll RandR (Resize and Rotate) erweitert, auf das die Anzeige-Konfigurationsprogramme von Gnome oder KDE sowie das Kommandozeilenprogramm Xrandr zurückgreifen. Damit sich Hybridgrafiktechniken über den X-Server 1.13 und RandR 1.5 nutzen lassen, müssen allerdings auch die anderen Teile des Grafikstacks zur Laufzeit zuschaltbare Grafikhardware unterstützen; darunter nicht nur die Grafiktreiber des X-Servers, sondern auch die Libdrm und ihre Treiber sowie die Grafiktreiber und das DMA-Subsystem im Kernel, der seit Linux 3.5 alles wichtige enthält. Die Erweiterungen für diese Komponenten wurden und werden unter dem Oberbegriff "Prime" entwickelt und ziehen gerade in die Entwicklerzweige der Linux-Distributionen ein. Auch Nvidia will den proprietären Linux-Treiber erweitern, um mittelfristig mit Hilfe der Prime-Infrastruktur Unterstützung für Optimus zu realisieren.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Wenn sich die Entwickler von X.org diese Woche zur X11-Entwicklerkonferenz in Nürnberg treffen, haben sie auch ein Jubiläum zu feiern. Denn X11, die bisher letzte Hauptversion des X Window Systems, wurde am 15. September 25 Jahre alt. An diesem Tag veröffenlichte ein Team um Robert Scheifler und im Gettys am MIT die erste Version von X11.

X11 ist eigentlich lediglich die aktuellste Inkarnation des X-Protokolls, das das X Window System definierte. Es war augenscheinlich nur eine Verfeinerung von X10, doch es enthielt eine entscheidende Änderung, die den Durchbruch bedeutete: Es war nicht mehr Hardware-abhängig.

Die Geschichte von Bitmap-Displays begann bereits in den 1970er-Jahren, wobei viele Ideen in Xerox PARC entwickelt wurden. Neben anderen Systemen entstand daraus das Fenstersystem W, das auf einem heute vergessenen Betriebssystem namens V lief. Der Nachfolger von W wurde am MIT aus der Taufe gehoben, ersetzte bereits 1984 W und erhielt den nächsten Buchstaben im Alphabet als Namen, das X. Nach dieser ersten Version, die als X1 bezeichnet wird, folgten schon 1985 X6 und X9 mit neuer Funktionalität, und X9 war die erste Version unter der MIT-Lizenz. Im gleichen Jahr folgte noch X10, das in vier Revisionen (bis X10R4) fast zwei Jahre aktuell blieb.

Dann trat X11 in Erscheinung und blieb trotz etlicher Revisionen bis heute die aktuelle Version. X11 überlebte dank seiner Leistungsfähigkeit, Zuverlässigkeit und ständigen Erneuerungen alle Entwicklungen für 25 Jahre, trotz der in unglaublicher Weise gestiegenen Leistungsfähigkeit der Hardware. Der Hauptgrund dafür dürfte in der Modularität des Systems liegen, die es vielen Entwicklern ermöglichte, gleichzeitig an dem System zu arbeiten, und die es möglich machte, einzelne Module zu erneuern oder zu ersetzen.

Einen großen Teil der Entwicklung leistete über einen langen Zeitraum das X Consortium, das von Unix-Herstellern finanziert wurde. Für die Portierung auf die entstehenden freien Betriebssysteme Linux und BSD wurde XFree86 gegründet, das mehr und mehr die Entwicklung übernahm und ab X11R6.4 schließlich allein für die Entwicklung verantwortlich war. Doch 2003 kam es zu einer Krise, als einige Entwickler von XFree86 die Lizenz ändern wollten, was von den meisten anderen abgelehnt wurde. Das Ergebnis war eine Abspaltung von XFree86 unter dem Namen X.org, die auch heute noch aktiv entwickelt wird. Die wenigen verbliebenen XFree86-Entwickler überdauerten noch einige Monate, dann wurde das Projekt eingestellt.

Lange Jahre konnte kein Grafiksystem X11 ersetzen, auch wenn es einige Konzepte und Prototypen gab. Erst in neuester Zeit führten gewisse Schwächen beim Compositing dazu, dass das System Wayland als Alternative entwickelt wird. Auch wenn Wayland vielleicht im nächsten Jahr beginnen wird, X11 in einzelnen Bereichen (Mobilgeräte oder Desktops für Heimrechner) abzulösen, eines ist sicher: X11 wird uns noch lange erhalten bleiben.

Quelle: www.pro-linux.de

[SiLæncer]

Kristian Høgsberg, der Initiator von Wayland, hat auf der X Developer Conference einen Prototypen von Wayland mit der Möglichkeit vorgestellt, Fenster von Programmen darzustellen, die auf anderen Rechnern laufen. Wayland 1.0 wird außerdem in Kürze erwartet.

Wayland ist ein Protokoll zwischen Compositor und Client-Applikationen sowie die entsprechende Implementation als C-Bibliothek. Der Compositor kann dabei ein eigenständiger Display-Server sein, wie der vom Projekt entwickelte Referenz-Compositor Weston, eine X-Anwendung oder ein Wayland-Client. Die Clients können traditionelle Anwendungen, X-Server oder andere Display-Server sein. Wayland und Weston bilden zusammen ein vollständiges Fenstersystem, das X in einigen Bereichen ablösen könnte. Details können der Architektur-Übersicht entnommen werden.

Damit Wayland X11 ablösen kann, sollten die wichtigsten Programme allerdings portiert sein - generell können zwar alle X11-Anwendungen mittels Xwayland unter Wayland ausgeführt werden, allerdings wäre damit nichts gewonnen. Ein Kritikpunkt an Wayland war jedoch bisher die fehlende Netzwerktransparenz im Vergleich zu X11, die damit begründet wurde, dass sie sich auf andere Weise erreichen ließe. Dieser Punkt wird nun wahrscheinlich wegfallen. In einem Vortrag auf der X Developer Conference 2012 in Nürnberg, von dem auch ein (über 80 Minuten langes) Video vorliegt, stellte Kristian Høgsberg, der Initiator von Wayland, einen Prototypen von Wayland vor, der Fenster von Programmen darstellen kann, die auf anderen Rechnern laufen. Das Protokoll hierfür wird als VNC-ähnlich beschrieben, überträgt also die Unterschiede im Fenster oder im ganzen Desktop, die von Grafikoperationen erzeugt werden. Wie Heise Online schreibt, befindet sich die entsprechende Passage im Video ab 1:11:50.

Außerdem soll Wayland 1.0 in den nächsten Wochen erscheinen. Diese Version wird sich aber noch nicht an Anwender richten, da es wohl noch einiges zu tun gibt. Das Protokoll sowie das API von Wayland sollen aber mit Version 1.0 endgültig sein. Sobald die Version 1.0 veröffentlicht wird, soll es keinerlei inkompatible Änderungen mehr geben. Damit wird Entwicklern von anderen Projekten eine stabile Basis für ihre Anpassungen oder Neuentwicklungen gegeben.

Quelle: www.pro-linux.de

[SiLæncer]

Wie bereits auf der X.Org Developer Conference im September angekündigt, hat Kristian Høgsberg jetzt die Version 1.0 des Grafiksystems Wayland und des Referenz-Compositors Weston veröffentlicht. Wayland, von Høgsberg als "Display Server Architecture" bezeichnet, soll unter Linux mittelfristig das X Window System (X11) ablösen. Ab der Version 1.0 soll es keine inkompatiblen Änderungen an den Programmierschnittstellen mehr geben, sodass die Entwickler von Compositoren wie Kwin, Compiz und Mutter sowie von Toolkits wie Gtk+, Qt und EFL eine stabile Grundlage haben.

Der ganze Artikel

Quelle : www.heise.de

[ritschibie]

Der Wayland-Fork Northwood will Compiz-
Effekte wie den Würfel für Wayland umsetzen.
(Bild: Compiz-Projekt)

Unter dem Namen Northfield hat der langjährige Compiz- und Wayland-Entwickler Scott Moreau einen Fork des Xorg-Nachfolgers Wayland eingerichtet. Er will dort mit dem Displayserver experimentieren und Compiz-Effekte implementieren.

Der ganze Artikel

Quelle: www.golem.de

[ritschibie]

Nachdem Kristian Høgsberg, Hauptentwickler von Wayland, bereits in der Vergangenheit ankündigte, seine Entwicklung künftig öfter zu veröffentlichen, steht nun mit der Version 1.1 eine neue Variante von Wayland und Weston zum Bezug bereit. Ganz planmässig verlief das Release allerdings nicht, denn eigentlich sollte Wayland 1.1 schon Ende März erscheinen. Høgsberg hat aber nach eigener Angabe noch auf eine wichtige Korrektur bei Zeitstempeln gewartet und die Freigabe verschoben.

Der ganze Artikel

Quelle: www.pro-linux.de

[SiLæncer]

Ein stabiles Programmierinterface für Display-Server und Unterstützung für Farbmanagement sind zwei der wichtigsten Neuerungen der Versionen 1.2 von Wayland und Weston, die jetzt erhältlich sind. Durch das stabile Server-API sollte ein für Wayland 1.2 übersetzter Compositor wie Weston auch mit späteren Wayland-Versionen zusammenarbeiten; laut der Freigabe-Mail sei dies stabile API sei jetzt nötig, weil langsam weitere Compositors für Wayland auftauchen. Das Protokoll für Wayland-Clients war schon bei Version 1.0 für stabil erklärt worden.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Der neue X-Server kann nun OpenGL nutzen, um Aufgaben an den Grafikchip zu delegieren. Neu dabei ist auch Systemd- und Xwayland-Unterstützung; letztere können Wayland-Compositor nutzen, um X11-Anwendungen auszuführen.

Anders als bei den letzten Versionssprüngen bringt der jetzt erhältliche X-Server 1.16 gleich einen ganzen Schwung wichtiger Neuerungen. Die wichtigste ist die Integration des vorher extern entwickelten "Glamor". Der X-Server von X.org, auf den alle Mainstream-Linux-Distributionen zur Darstellung der grafischen Bedienoberflächen zurückgreifen, kann dadurch OpenGL-Befehle nutzen, um Oberflächenelementen zu zeichnen und zusammenzusetzen.

Wie andere 3D-Anwendungen verarbeitet der X-Server die OpenGL-Befehle nicht selbst, sondern überlässt das den unabhängig von X.org entwickelten OpenGL-Treibern – etwa jenen von Mesa 3D, das Linux-Distributionen standardmäßig einrichten. Glamor kann so die Entwicklung der X-Server-Treiber enorm erleichtern, denn die haben bislang zumeist 2D-Beschleunigungs-Verfahren wie EXA implementieren müssen, damit die Treiber ausreichend Performance liefern. Genau wie es Glamor nun über OpenGL-Treiber macht, delegieren diese Techniken die Zeichenaufgaben an den Grafikchip, was den Prozessor entlastet und die Performance verbessert.

Der ganze Artikel

Quelle : www.heise.de