Fryboyter

SDDM könnte ein offizielles KDE-Projekt werden

Kürzlich habe ich in einem Artikel kritisiert, dass seit November 2020 keine neue offizielle Version des Displaymanagers SDDM veröffentlicht wurde, obwohl dieser aktiv weiterentwickelt wird und zudem zwischenzeitlich einige nervige Bugs behoben wurden. Mit etwas Glück könnte sich das in absehbarer Zeit ändern.

Nate Graham hat den Vorschlag gemacht, aus SDDM ein offizielles KDE-Projekt zu machen. Zumal ein Großteil aller Entwickler von SDDM auch KDE-Entwickler sind. SDDM würde sich dann ggf. auch am Release-Zyklus von Plasma orientieren, sodass regelmäßig neue Versionen veröffentlicht würden. Wenn alle klappt wie vorgeschlagen, dann könnte SDDM bereits Teil von Plasma 6 sein.

Sddm - Warum etwas entwickeln aber nicht veröffentlichen?

Wer KDE Plasma nutzt, wird mit ziemlicher Wahrscheinlichkeit auch den Displaymanager sddm verwenden. Dieser wird als eigenständiges Projekt auch aktiv weiterentwickelt. So wurden beispielsweise diesen Monat bisher 6 Commits erstellt. Im März waren es 11. Trotzdem habe ich und andere Nutzer immer noch mit bekannten Bugs zu kämpfen.

So benötigten aktuell alle meine Rechner mit Plasma ca. 14 Sekunden um sddm zu beenden. Ja, davon geht die Welt nicht unter. Aber es nervt. Vor allem, weil der Bug an sich scheinbar schon behoben ist. Denn ich habe vor einigen Tagen einfach mal die Git-Version anstelle der aktuellen offiziellen Version 0.19.0 installiert (im AUR als sddm-git zu finden). Seit dem ist das Problem mit der langen Wartezeit beim Herunterfahren verschwunden. Sobald ich wieder die Version 0.19.0 installiere, tritt das Problem wieder auf.

Nun werden einige sagen, dass ich doch einfach auf die Veröffentlichung der nächsten Version warten soll. Das ist aber genau das Problem. Version 0.19.0 wurde im November 2020 veröffentlicht. Seit dem wurde schon mehrmals um die Veröffentlichung einer neuen Version gebeten. Zum Beispiel unter https://github.com/sddm/sddm/issues/1471. Unter anderem, weil ja zwischenzeitlich andere Verbesserungen gemacht wurden und nicht nur der von mir beschriebene Bug behoben wurde.

Ich kann es ja verstehen, dass man ein neues Release möglichst fehlerfrei veröffentlichen möchte. Und vielleicht auch noch die eine oder andere neue Funktion einbauen will. Aber wenn seit der letzten offiziellen Version bereits einige Bugs behoben wurden, die den Nutzern auf die Nerven gehen, und mehrere Jahre vergangen sind, warum kann man nicht einfach ein Bugfix-Release veröffentlichen? Also Version 0.19.1 und nicht 20.0.0? Dann kann man ja weiterhin am “perfekten” Release arbeiten.

Ich für meinen Teil werde erst einmal die derzeit aktuelle Version von sddm-git weiter nutzen, was inzwischen wohl auch einige andere Nutzer machen, die nicht mehr auf eine neue offizielle Version warten wollen. Bisher scheint damit ja alles zu funktionieren und ich bin daher nicht gezwungen weitere Updates zu installieren. Denn auf einen anderen Displaymanager möchte ich möglichst nicht wechseln.

Sddm - Nur auf einem Monitor anmelden

Achtung dieser Artikel löst ein Luxusproblem! An meinem Hauptrechner sind zwei Monitore angeschlossen und als Display Manager nutze ich SDDM. SDDM hat bei mehreren Monitoren die Angewohnheit, auf allen Monitoren das Gleiche angezeigt, sodass man sich prinzipiell über jeden Monitor anmelden kann. Mich nervt das aber irgendwie; zumal ich mich immer an dem Monitor anmelde, der direkt vor mir steht. Wie gesagt, ein Luxusproblem.

SDDM sieht es selbst aktuell nicht vor, dass die Eingabemaske nur auf einem Monitor erscheint. Also ist wieder Handarbeit nötig. Hierfür benötigt man das Tool xrandr. Unter Arch hat das Paket die Bezeichnung xorg-xrandr.

Mittels xrandr | grep ’ connected’ lässt man sich als Erstes die angeschlossenen Monitore anzeigen und sucht sich denjenigen heraus, den man unter SDDM nicht nutzen will. Bei mir ist das relativ leicht, da dieser die geringere Auflösung hat. Nehmen wir einmal folgendes Beispiel

(Standardeingabe):20:DP-4 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm

Der Monitor ist in diesem Fall also über den Anschluss DP-4 angeschlossen. Nun erstellt man das Script /usr/share/sddm/scripts/Xsetup und trägt Folgendes ein.

#!/bin/sh
xrandr --output DP-4 --off

DP-4 muss man natürlich an die eigenen Gegebenheiten anpassen.

Nun trägt man noch folgendes in die Datei /etc/sddm.conf ein (wenn die Datei nicht vorhanden ist, einfach anlegen).

[XDisplay]
DisplayCommand=/usr/share/sddm/scripts/Xsetup

Bootet man den Rechner nun neu, sollte der im Script genannte Monitor bei Einloggen nichts mehr anzeigen. Sobald man sich angemeldet hat, ist der Monitor aber wieder automatisch nutzbar.

Wie Probleme zwischen sddm und den Nvidia-Treibern mein Problem mit Steam gelöst haben

Vor ein paar Wochen wurden die Nvidia-Treiber unter Arch auf Version 378.13 aktualisiert. Eine Installation und ein Neustart hatten immer einen black Screen auf beiden Monitoren zur Folge. Journalctl war der Meinung, dass sddm nichts mit der OpenGL-Version anfangen kann (Unrecognized OpenGL Version).

Da alle Suchergebnisse, die sich auf “Unrecognized OpenGL Version” beziehen, absolut nichts gebracht haben, habe ich ein Downgrade der Pakete nvidia-dkms sowie nvidia-utils gewagt. Hierzu habe ich das Tool downgrade aus dem AUR verwendet und beide Pakete in Version 375.26-2 installiert. Und siehe da, sddm hat wieder funktioniert und ich konnte mich normal an KDE Plasma anmelden.

Am Wochenende hatte ich jetzt mal etwas Zeit und ich habe mich auf das Problem gestürzt, da man Downgrades unter Arch eigentlich vermeiden sollte. Da Version 375.26-2 ja funktioniert ging ich davon aus, dass Version 378.13 das Problem ist. Und ich sollte mich irren. Nach x Fehlversuchen habe ich wieder die alte, funktionierende Version der Nvidia-Treiber installiert und wollte fürs Erste erst einmal aufgeben. Irgendwie bin ich dann noch auf die Idee gekommen mir glxinfo aus dem AUR zu installieren. Nachdem ich dann glxinfo | grep OpenGL ausgeführt habe, ist mir mein Gesicht mal so richtig eingeschlafen. Eigentlich hatte ich erwartet, dass die Ausgabe etwas mit Nvidia ausspuckt. Stattdessen wurde ich mit Mesa konfrontiert. Um es mal mit dem fränkischen Fragewort auszudrücken… Hä?

Böses ahnend habe ich dann mal nachgeschaut, ob die Pakete nvidia-libgl und lib32-nvidia-libgl installiert sind. Natürlich nicht. Aber warum nicht? Ich bin mir absolut sicher, dass ich diese Pakete installiert hatte. Und ich habe absolut keinen Schimmer warum ich diese deinstalliert haben sollte. Hier wären wir dann wieder beim fränkischen Fragewort mit zwei Buchstaben.

Nachdem ich dann beide Pakete installiert und die Nvidia-Treiber aktualisiert hatte, hatte auch sddm wieder ein Einsehen und der Rechner konnte wie gewohnt gestartet werden.

Einen schönen Nebeneffekt hat das Ganze auch noch. Vor einigen Wochen hatte ich nach einem Update von Steam festgestellt, dass alle Spiele total ruckeln und quasi unspielbar waren. Da ich aktuell fast nur Overwatch bzw. Quake Live unter Windows spiele, habe ich mich damit aber nicht befasst. Aber wenigstens hatte ich am Wochenende mal einen halbwegs vorzeigbaren Geistesblitz und habe 1 und 1 zusammengezählt. Nach mehreren Runden CS:GO war ich mir sicher, dass das Problem mit Steam ebenfalls an den fehlenden libgl-Paketen lag.

Warum aber Version 375.26-2 funktioniert und wieso die libgl-Pakete bei mir nicht (mehr) installiert waren, wird wohl ein Rätsel bleiben. Allerdings haben auch einige andere Arch-Nutzer die sddm einsetzen mit den aktuellen Nvidia-Treibern einen Blackscreen. Vielleicht liegt das Problem dieses eine mal nicht auf meiner Seite…