Warum wird die GNOME Shell bei mehreren Bildschirmen nicht korrekt skaliert?
- Grundlegendes zur Skalierung in GNOME Shell
- Technische Ursachen: unterschiedliche DPIs und Protokollgrenzen
- Praktische Folgen: Artefakte und Inkonsistenzen
- Treiber, Wayland vs. X11 und Drittsoftware
- Ausblick und praktische Tipps
Grundlegendes zur Skalierung in GNOME Shell
GNOME Shell verwendet für die Skalierung von UI-Elementen eine Kombination aus Wayland/X11-Interna, Toolkit-Skalierung (GTK) und Compositor-Logik. Während bei einem einzelnen Bildschirm mit nativer DPI meist eine einfache Ganzzahlskalierung (100 %, 200 %) funktioniert, treten bei mehreren Monitoren mit unterschiedlichen Pixel-Dichten oder Auflösungen Konflikte auf. Die Shell versucht, konsistente Fenster-, Panel- und Shell-UI-Größen bereitzustellen, stößt dabei aber auf Einschränkungen in Protokollen und Toolkits, die zu Inkonsistenzen führen.
Technische Ursachen: unterschiedliche DPIs und Protokollgrenzen
Eine zentrale Schwierigkeit ist, dass viele Komponenten Ganzzahlskalierung voraussetzen oder nur begrenzte Unterstützung für skalierte Fenstergrößen bieten. X11 und ältere Xorg-Toolchains haben kein standardisiertes, monitorbasiertes Skalierungsmodell; Wayland führt zwar per-monitor scaling ein, aber nicht alle Anwendungen oder Toolkits implementieren dieses vollständig. GTK und die Shell müssen Pixel- bzw. logische Einheiten umrechnen, und wenn zwei Bildschirme unterschiedliche DPI-Werte haben, müssen Fenster beim Verschieben zwischen Bildschirmen entweder neu skaliert oder auf einer gemeinsamen logischen Skala dargestellt werden. GNOME Shell wählt oft eine einheitliche Skalierung für die Shell-Oberfläche, sodass Elemente auf einem Monitor zu groß und auf dem anderen zu klein wirken.
Praktische Folgen: Artefakte und Inkonsistenzen
Als Folge sieht man unscharfe Texte und Icons, falsch skalierte Fensterrahmen, überlappende oder abgeschnittene Panel-Elemente sowie flackernde oder verzerrte Darstellungen beim Verschieben von Fenstern. Manche Anwendungen rendern in physikalischen Pixeln (resultierend in zu kleiner Darstellung auf hochauflösenden Bildschirmen) oder in logischen Einheiten (die auf einem Bildschirm korrekt, auf dem anderen nicht). Hingegen unterstützt die GNOME Shell selbst zwar High-DPI in aktuellen Versionen besser, doch Drittanwendungen, X11-Fenstermanager-Workarounds und proprietäre Grafikkartentreiber können weiterhin Probleme verursachen.
Treiber, Wayland vs. X11 und Drittsoftware
Grafikkartentreiber spielen eine große Rolle: Proprietäre Treiber oder ältere Treiberimplementierungen können Wayland-Funktionalitäten oder die erforderlichen Randbedingungen für saubere Skalierung nicht vollständig unterstützen. Viele Anwender betreiben weiterhin X11-Kompatibilitätslayer (XWayland); XWayland skaliert Fenster nicht immer korrekt zwischen verschiedenen DPIs, was zu Unstimmigkeiten führt. Anwendungen, die ihre eigene Skalierungslogik haben oder GTK-/Qt-Versionen verwenden, die keine per-monitor-Skalierung unterstützen, tragen zusätzlich zu Inkonsistenzen bei.
Ausblick und praktische Tipps
Die langfristige Lösung liegt in komplettem Wayland-Ökosystem-Support, besserer Toolkit-Integration und konsistenten Treiber-Implementierungen, sodass per-monitor scaling reibungslos funktioniert. Kurzfristig helfen Workarounds wie einheitliche Skalierungsfaktoren für alle Monitore, Aktualisierung von GTK/Qt, Verwendung aktueller Mesa- und Treiberpakete sowie wenn möglich native Wayland-Sitzungen statt X11. Manche Nutzer setzen auf fractional-scaling-Optionen in GNOME (experimentell), was Verbesserungen bringt, aber noch nicht überall perfekt ist.