News Linux: Ubuntu 17.10 Artful Aardvark mit Wayland als Standard

[Surtalnar]

Ein standardmässiges installiertes Debian Stretch System mit GNOME3 nutzt immer noch den xorg-server, da der GNOME Display Server (gdm3) eine xserver-xorg Abhängigkeit hat [1, 2].

[1] https://packages.debian.org/stretch/gdm3
[2] https://wiki.debian.org/Xorg

Danke.

Selbst bei Buster/Sid ist diese Abhängigkeit noch vorhanden. Schade.

 

[xandery]

Danke.

Selbst bei Buster/Sid ist diese Abh?ngigkeit noch vorhanden. Schade.

Sorry, ich haette mich besser ausdruecken und informieren sollen ^^. Mit anderen Worten, die Default GNOME Session bei Debian Stretch nutzt noch immer eine X11 session. Du kannst aber beim GNOME3 Login Screen (gdm3) zwischen einer "Gnome on Wayland" Session oder "Gnome on X11" Session auswaehlen. Hier ist ein kleiner Screenshot, der das grob veranschaulicht :-).



Um zu testen ob dein Debian System wirklich Wayland nutzt kannst du den Befehl "echo $XDG_SESSION_TYPE" nutzen. Dieser sollte die Zeichenkette "wayland" ausgeben:

 

[zett0]

Da 18.04 ein LTS ist, würde es, wenn ohne Wayland als Standard ausgeliefert, auch für 5 Jahre so bleiben.

Da 16.04 auch LTS hat und x.org verwendet sind es doch nur 2 weitere Jahre

 

[Iapetos]

Interessant. In Fedora läuft GDM schon seit Fedora 24 unter Wayland. Die Xorg-Abhängigkeit von GDM ist unabhängig von der zu startenden Gnome-Sitzung, also könnte auch Debian standardmäßig mit Wayland starten.

 

[xandery]

Interessant. In Fedora läuft GDM schon seit Fedora 24 unter Wayland. Die Xorg-Abhängigkeit von GDM ist unabhängig von der zu startenden Gnome-Sitzung, also könnte auch Debian standardmäßig mit Wayland starten.

Genau so ist es . Ich nutze gerade Wayland auf meinen Debian Sid System. Enige Programme wie der SimpleScreenRecorder funktionieren jedoch noch nicht unter Wayland mit Debian Sid.

Bei Debian ist jedoch die Xorg-Abhängigkeit bei gdm3 nicht absolut. Ich denke, dass ich nun den Zusammenhang zwischen GDM3, Mutter, und Wayland grob begriffen habe . GDM3 ist nur ein Display Manager und natuerlich kein Display Server . Vereinfacht gesagt ist GDM3 nur ein grafischer Login Manager, der eine X11 Session oder eine Wayland Session starten kann. Deshalb hat das Debian-Paket eine Xorg-Abhängigkeit.

Bei dem Wayland-Protokoll ist es nun so dass Implementationen eines Wayland-Compositor zwei Rollen uebernehmen koennen. Einerseits die des Display Servers und andererseits die des Window Managers. Bei GNOME3 implementiert zum Beispiel der Window Manager Mutter einen Wayland-Compositor, daher ist Debian eigentlich schon seit Jessie (GNOME 3.14) Wayland-Ready, weil der Window Manager in GNOME 3.10 schon bereits eine experimentelle Wayland-Unterstützung enthielt [1].

[1] https://de.wikipedia.org/wiki/Wayland_(Anzeige-Server)#Wayland_Compositor

 

[Iapetos]

Tatsächlich vereint ein Wayland-Compositor den Window-Manager, den Compositing-Manager und den Display-Server. Dabei geht viel Overhead verloren. Ich freue mich schon auf Schlanke Compositors, die mein Netbook nicht über Gebühr beanspruchen.

 

[mensch183]

Ich freue mich schon auf Schlanke Compositors, die mein Netbook nicht über Gebühr beanspruchen.

Schlankheit ist da nicht so das Problem finde ich. Minimalistische (und dadurch eher unbenutzbare) gibts genug. Wayland scheitert bei mir an einem Ersatz für fvwm, also einem ähnlich detailliert konfigurierbarem compositor.

 

[tuxnix]

Da 16.04 auch LTS hat und x.org verwendet sind es doch nur 2 weitere Jahre

Man kann sich auch mach mal dümmer stellen als man ist, nur um dann noch so besser Klugscheißern zu können.
Oder hast du tatsächlich die Zusammenhänge nicht kapiert?

1. Wayland ist der neue Standard.
2. Xorg bleibt noch lange erhalten.
3. Ubuntu richtet sich jetzt auf den neuen Standard ein. Ansonsten müssten sie es irgendwann später tun. Dann hätten sie a) jetzt etwas verpasst und b) einiges andere länger am Bein.
4. Wie lange xorg noch weiter existiert weiß heute ohnehin noch niemand.

Noch Fragen?

 

[Bruddelsupp]

Dank fürs abwürgen des fruchtbaren Austauschs. Warum so aggressiv?

 

[xandery]

Mit Fedora u. Ubuntu 17.10 bekommt Wayland dank GNOME ordentlich an Verbreitung. KDE wird hoffentlich mit Plasma 5.11 folgen und Wayland auch standardmäßig unterstützen. Wie schaut es aber mit Cinnamon, XFCE, Mate, LXQt u. den weitern anderen Desktop Oberflächen aus?

Also bei MATE, XFCE und LXQt ist die Wayland-Unterstützung geplannt [1, 2, 3]. Die XFCE Entwickler haben genauso wie die MATE Entwickler erst kürzlich ihre Codebasis auf Gtk3+ portiert. Die MATE Entwickler wollen beispielsweise den Mir Display Server von Unity als Wayland-Compositor recyclen [4], da es ein zur grosser Aufwand sei ihr Window Manager Macro (ein Fork Metacity/GNOME 2) Wayland-Ready zu machen, sprich in einen Wayland-Compositor umzuwandeln wie Mutter. Eine andere Variante wäre das Projekt Mutter zu forken und anzupassen, aber dann hätte das MATE Projekt eine GNOME3 Abhängigkeit geschaffen.

Bei den Cinnamon/Linux Mint "Entwicklern" gibt es zurzeit nur Mimimi wegen Wayland-Support [5]. Mit anderen Worten, viel Lärm um Nichts, da sie zwangsweise Wayland-Support in ihrem Window Manager Muffin (ein Fork von Mutter) und ihrer Cinnamon Shell (Fork von GNOME Shell) in irgendeiner Form hineinfricklen müssen. Sonst wird Cinnamon obsolet.
Wenn das nicht klappt, können sie ihrer Mentalität treu bleiben und wieder GNOME Shell und Mutter forken .

[1] http://wiki.mate-desktop.org/wayland
[2] https://xfce.org/download/changelogs/4.12
[3] https://github.com/lxde/lxqt/wiki/TODO-for-Wayland
[4] http://www.omgubuntu.co.uk/2017/06/mir-live-wayland-compositor-mate-desktop
[5] https://github.com/linuxmint/Cinnamon/issues/5201

 

[tuxnix]

Dank fürs abwürgen des fruchtbaren Austauschs. Warum so aggressiv?

Danke für deinen Hinweis und ein "Bitte entschuldige" auch an zett0 wenn ich hier nicht den rechten Ton getroffen habe.
Ich fand den Artikel sehr informativ und es ärgert mich dann schon wenn sich Leute wiederholt am unwichtigsten, etwas unpräzise formulierten, Nebensatz fest beißen und nicht locker lassen wollen.
Aber sorry, mein Ton war dann doch etwas direkt.

 

[blackiwid]

Tatsächlich vereint ein Wayland-Compositor den Window-Manager, den Compositing-Manager und den Display-Server. Dabei geht viel Overhead verloren. Ich freue mich schon auf Schlanke Compositors, die mein Netbook nicht über Gebühr beanspruchen.

Soweit ich das gestern beim lesen eines reggit eintrages eines entwicklers gelesen habe duerfte der ramverbrauch eher steigen, zumindest wenn man mehr als 2,3 fenster gleichzeitig auf hat.

Dafuer hat man kein tearing mehr und CPU belastung sollte auch leicht zurueck gehen.

Das fehlende tearing sollte ein schnelleres feeling erzeugen ein bisschen. Das wohl das was der user am ehesten merkt. Startspeed koennte auch besser sein, vermute ich mal.

 

[aufkrawall]

OGL-Compositoren für Xorg haben das Tearing mit Vsync bereits zu 100% beseitigt. Das ist aber leider so eine Schwachstelle der Grafiktreiber (Nvidia) auf Linux (und wohl auch der Compositoren selbst), da klemmts gerne. Bei Konfigurationen >60Hz und gar noch Multimonitor nimmt die Wahrscheinlichkeit für Probleme dann noch exponentiell zu.
Prinzipiell ist aber auch mit Xorg ein völlig tearing- und ruckelfreier Fensterbetrieb möglich.

 

[Iapetos]

Stimmt. Und es ist ganz schön fummelig und benötigt, wie du bereits bemerkt hast, für jeden Treiber andere Einstellungen. Ich mag Compton sehr gern, allerdings bin ich auch an den vielen Einstellungsmöglichkeiten und einem bockigen Nvidia-Treiber beinahe wahnsinnig geworden. Zudem steigt der Overhead bei Compositing über GLX enorm, ist also eher nichts für schwachbrüstige Systeme. Wayland hingegen läuft auch im Software-Modus ohne Grafikbeschleunigung.

 

[DonConto]

And that would be?

Schande über mich Beim zweiten Lesen war es klar. Sorry

 

[aufkrawall]

Stimmt. Und es ist ganz schön fummelig und benötigt, wie du bereits bemerkt hast, für jeden Treiber andere Einstellungen. Ich mag Compton sehr gern, allerdings bin ich auch an den vielen Einstellungsmöglichkeiten und einem bockigen Nvidia-Treiber beinahe wahnsinnig geworden. Zudem steigt der Overhead bei Compositing über GLX enorm, ist also eher nichts für schwachbrüstige Systeme. Wayland hingegen läuft auch im Software-Modus ohne Grafikbeschleunigung.

Ich hab die besten Erfahrungen mit KWins Compositor gemacht. Compton funktioniert mit NV unter KDE leider nicht richtig (auch nicht mit abgeschaltetem KWin-Compositor). Mit anderen Compositoren als KWin bewegen sich OGL-Fenster ruckelig oder es gibt sonst wie Probleme.
Nvidia hat auch allgemein ein Problen mit Xorg, dass die Performance beim Einblenden von Fenstern einbricht, unabhängig von einem Compositor.
Moderne Compositoren sollten eigentlich nicht viel Overhead haben, KWin lief etwa auf meiner Skylake IGP mit 75Hz von der Performance her genau so gut wie Windows 10 (mit experimentellem Intel-Vsync, mit dem man den Compositor besser nachträglich nciht anhalten sollte wegen Deadlocks).
Für Nvidia + KWin kann ich nur den __GL_YIELD="USLEEP" Trick empfehlen.

 

[DEFCON2]

OGL-Compositoren für Xorg haben das Tearing mit Vsync bereits zu 100% beseitigt.

Könntest du mir da vielleicht ein paar Schlagwörter zum Suchen geben? Habe hier unter Ubuntu GNOME mit besagter 1050Ti sagenhaftes Tearing beim Scroolen in Emacs.

 

[Iapetos]

Dieses Tutorial könnte dir vielleicht helfen. Nvidia ist für seine "Workarounds" berüchtigt.

 

[DEFCON2]

Danke für den Link. Leider gibt es die Einstellungen im aktuellen proprietären NVIDIA Treiber natürlich schon nicht mehr . Dennoch hat es schon eine deutliche Verbesserung gebracht diesen anstatt dem nouveau Treiber zu installieren.

 

[Iapetos]

Pascal-GPUs können unter Nouveau erst seit Linux 4.12 hardware-beschleunigt arbeiten. Hast du einen so aktuellen Kernel installiert? (Fedora bekam ihn erst diese Woche.)

Bezüglich Tearing und Nouveau (aus der Nouveau-Manpage):

Option "GLXVBlank" "boolean"
Synchronize GLX clients to VBlank. Useful where tearing is a problem, harmful if the GPU isn't fast enough to keep up with the monitor refresh rate. Default: on.

Option "SwapLimit" "integer"
Set maximum allowed number of pending OpenGL double-buffer swaps for a drawable before a client is blocked. A value of 1 corresponds to double-buffering. A value of 2 corresponds to triple-buffering. Higher values may allow higher framerate, but also increase lag for interactive applications, e.g., games. Nouveau currently reliably supports a maximum value of 2 on XOrg 1.12+. A maximum setting of 2 on older x-servers is allowed, but it will break conformance with the OpenML OML_sync_control specification and will cause failure of soft‐ ware that relies on correct presentation timing behaviour as defined in that specification. Default: 1.

Wenn du also unter /etc/X11/xorg.conf.d/20-nouveau.conf folgendes ablegst, könnte das Tearing unter Nouveau verschwinden (YMMV):

Section "Device"
Identifier "GP107"
Driver "nouveau"
Option "GLXVBlank" "true"
Option "SwapLimit" "2"
EndSection

Unter Wayland sollte Tearing in der Regel gar nicht stattfinden.