Die naheliegende Lösung: /etc/fstab plus ein Dispatcher-Skript für NetworkManager, das anhand von SSID oder Server-Erreichbarkeit automatisch mountet. Klingt nach einer Feierabend-Sache. Ist es aber nicht ganz – ich bin dabei über drei Stolperfallen gestolpert, die einem erst auffallen, wenn der Rechner runterfährt, aufwacht oder in den Standby soll. Genau die drei nehme ich hier mit euch durch.

Getestet habe ich das Ganze auf Arch Linux, aber das Setup ist nicht Arch-spezifisch: Solange eure Distribution systemd und NetworkManager mitbringt – also etwa auch Fedora, Ubuntu, Debian oder openSUSE –, funktioniert alles hier eins zu eins.

Der Grundaufbau

Netzwerkfreigaben bekommen in der fstab klassischerweise noauto, damit sie beim Boot nicht sofort, sondern erst bei Bedarf eingehängt werden:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0

Für den Mount-Typ selbst gibt’s je nach Protokoll gute Anleitungen im Arch Wiki, etwa zu Samba/CIFS und zu davfs2 für WebDAV – beide funktionieren unabhängig von der Distribution, solange cifs-utils beziehungsweise davfs2 installiert sind.

Das eigentliche Mounten übernimmt dann ein Skript unter /etc/NetworkManager/dispatcher.d/. NetworkManager ruft solche Skripte bei jeder Verbindungsänderung auf und übergibt Interface und Status (up, down, pre-down und ein paar weitere) mit – alle Details dazu stehen in der NetworkManager-dispatcher-Manpage. Ein simples Skript prüft die aktive WLAN-SSID und mountet, wenn’s passt:

#!/bin/bash
IFACE="$1"
STATUS="$2"

case "$STATUS" in
    up)
        SSID=$(nmcli -t -f active,ssid dev wifi | awk -F: '$1 == "yes" {print $2; exit}')
        if [[ "$SSID" == "MeinHeimnetz" ]]; then
            mount /mnt/server/home
            mount /mnt/server/data
        fi
        ;;
    down)
        umount /mnt/server/home
        umount /mnt/server/data
        ;;
esac

Fertig, oder? Nicht ganz. Sobald ihr das System runterfahrt, aus dem Standby weckt oder in den Standby schickt, zeigt sich, dass die Sache Tücken hat.

Warum nicht einfach GVfs?

Ihr fragt euch jetzt vielleicht, wieso ich mir das mit fstab und Dispatcher-Skripten überhaupt antue – GNOME bietet über „Mit Server verbinden“ im Dateimanager doch einen viel einfacheren Weg, Netzwerkfreigaben per SMB oder WebDAV einzubinden. Genau da liegt für mich das Problem.

Solche Mounts laufen nicht über den Kernel, sondern über GVfs, GNOMEs virtuelles Dateisystem. Programme, die die GIO-Bibliothek nutzen – fast alle GTK-Anwendungen, allen voran der Dateimanager selbst –, sprechen Freigaben direkt über eigene URIs wie smb:// oder dav:// an und zeigen entsprechend auch Vorschaubilder und Metadaten korrekt an. Für Programme, die das nicht können, blendet GVfs die Freigabe zusätzlich unter /run/user/<uid>/gvfs als ganz normalen Pfad ein. Diese Brücke läuft tatsächlich über FUSE – GVfs selbst ist zwar kein klassisches FUSE-Dateisystem, sondern eine eigene Architektur mit Daemon-Prozessen pro Protokoll, stellt aber genau für diesen Fall über gvfsd-fuse einen POSIX-kompatiblen Pfad bereit.

Genau diese Brücke ist bei mir der Knackpunkt: Nicht jedes Programm kommt damit zuverlässig klar. Konkret zeigt sich das bei mir in einem Markdown-Editor, in den ich auch Bilder für Artikel einbinde. Der Dateimanager zeigt die Bilder auf dem Netzlaufwerk ganz normal an, weil er GVfs nativ spricht. Der Markdown-Editor dagegen zeigt für dasselbe Bild nur einen Platzhalter – die Einbindung über den FUSE-Pfad funktioniert schlicht nicht zuverlässig, obwohl die Datei nachweislich da ist.

Ein klassischer Kernel-Mount über CIFS oder davfs2, wie im Rest dieses Artikels beschrieben, taucht dagegen als ganz normaler, stabiler POSIX-Pfad im Dateisystem auf – ohne Sonderbehandlung, für jedes Programm gleich. Der Mehraufwand mit fstab und Dispatcher-Skripten zahlt sich also gerade dann aus, wenn ihr Freigaben nicht nur im Dateimanager, sondern in ganz unterschiedlichen Anwendungen zuverlässig nutzen wollt.

Problem 1: Der Rechner fährt nicht mehr sauber runter

Fehlt in der fstab die Option _netdev, weiß systemd nicht, dass es sich hier um eine Netzwerkfreigabe handelt. Beim Shutdown kann es dann passieren, dass systemd versucht auszuhängen, nachdem das Netzwerk schon weg ist – der umount blockiert, bis der Job-Timeout greift, und euer System hängt beim Herunterfahren fest.

_netdev behebt das, weil systemd damit die richtige Reihenfolge kennt: erst aushängen, dann Netzwerk kappen. Wichtig ist außerdem, dass ein Dispatcher-Skript nicht nur auf down, sondern auf pre-down reagiert – der Status feuert, bevor die Verbindung wirklich fällt, während down schon danach kommt und für ein sauberes Aushängen zu spät ist. Damit das klappt, braucht es zusätzlich einen Symlink im Unterordner pre-down.d/.

Problem 2: Nach dem Aufwachen hängt sich der Dateimanager auf

Ein mount-Aufruf für CIFS oder WebDAV läuft im Kernel und kann bei nicht erreichbarem Server ziemlich lange blockieren – gerade kurz nach dem Aufwachen, wenn DNS oder Routing noch nicht ganz da sind. NetworkManager wartet standardmäßig synchron, bis so ein Dispatcher-Skript fertig ist, bevor es weitermacht. Hängt der mount-Aufruf, hängt bei euch plötzlich auch der Dateimanager oder die Netzwerkanzeige, weil die vom Verbindungsstatus abhängen.

Die Lösung: Mount-Versuche einfach im Hintergrund laufen lassen, damit das Dispatcher-Skript selbst sofort zurückkehrt, egal wie lange der eigentliche Mount braucht.

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

Problem 3: Der Standby funktioniert plötzlich nicht mehr

Und hier wird’s spannend. Mit der Lösung aus Problem 2 stolpert ihr in ein neues, deutlich fieseres Problem, das sich in meinem Fall so äußerte: Der Bildschirm geht aus, aber Tastaturbeleuchtung und LEDs bleiben an – ihr müsst hart abschalten. Was war passiert?

Der mount-Syscall für CIFS oder davfs blockiert bei nicht erreichbarem Server im sogenannten D-Zustand (uninterruptible sleep) – einem Zustand, den kein Signal unterbricht, auch SIGKILL nicht. Bevor der Kernel tatsächlich schlafen legt, versucht er, alle Prozesse einzufrieren. Ein Prozess im D-Zustand lässt sich aber nicht einfrieren, und der ganze Standby hängt fest, bis die Netzwerkoperation im Kernel von selbst aufgibt – das kann durchaus ein paar Minuten dauern.

Weil die Mount-Versuche aus Problem 2 jetzt länger im Hintergrund weiterlaufen, steigt eben auch die Chance, dass genau in dem Moment, in dem ihr in Standby gehen wollt, so ein blockierender Verbindungsversuch gerade aktiv ist.

Der zuverlässige Ausweg: Vor jedem mount erst mit einem echten Userspace-Verbindungstest prüfen, ob der Server überhaupt erreichbar ist – so einer lässt sich per Timeout wirklich abbrechen, zum Beispiel über Bashs eingebautes /dev/tcp:

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

Nur wenn der Test klappt, folgt der eigentliche mount. Damit landet ihr so gut wie nie mehr im riskanten, blockierenden Kernel-Connect, weil ihr zu dem Zeitpunkt schon wisst, dass der Server da ist.

Die Kombination, die bei mir funktioniert

Am Ende braucht ein robustes Setup vier Zutaten:

• _netdev in der fstab, damit systemd Netzwerkfreigaben beim Herunterfahren richtig einordnet.
• pre-down-Handling samt Symlink in pre-down.d/, damit das Aushängen garantiert vor dem Verbindungsabbau passiert – mit Timeout und Lazy-Unmount als Backup, falls der normale umount mal zickt.
• Asynchrone Mounts im up-Fall, damit NetworkManager und alles, was davon abhängt, nicht blockiert.
• Ein Erreichbarkeitstest vor jedem mount, damit der eigentliche, potenziell blockierende Kernel-Connect gar nicht erst passiert.

Dazu noch ein kleiner Healthcheck per systemd-Timer, der ein paar Minuten nach dem Boot und danach regelmäßig nachschaut, ob die Freigaben wirklich da sind, und notfalls nachhilft. Praktisch, falls der auslösende Netzwerk-Event mal zu früh oder zu spät kommt.

Alle Dateien im Überblick

Damit ihr das Ganze direkt nachbauen könnt, hier der komplette Satz an Dateien. Ich habe die Beispielnamen aus meinem eigenen Setup (ein Samba-Server namens bender, WebDAV via tuxedo) durch generische Platzhalter ersetzt – die müsst ihr natürlich an eure eigene Umgebung anpassen.

/etc/fstab – die beiden Freigaben, einmal Samba, einmal WebDAV:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
https://cloud.example.com/remote.php/dav/files/user /mnt/webdav davfs noauto,_netdev,uid=1000,gid=100,x-systemd.automount,x-systemd.idle-timeout=300,x-systemd.mount-timeout=15s 0 0

Die fstab referenziert die Zugangsdaten nur, gespeichert werden sie in eigenen Dateien – schon damit das Passwort nicht im Klartext in einer Datei steht, die jeder lesen kann.

/etc/samba/server.credentials – Zugangsdaten für die Samba-Freigabe:

username=maxmuster
password=GeheimesPasswort123

/etc/davfs2/secrets – Zugangsdaten für die WebDAV-Freigabe, referenziert wird hier der Mountpunkt statt einer Option in der fstab:

/mnt/webdav maxmuster GeheimesPasswort123

Beide Dateien gehören root und dürfen für niemand sonst lesbar sein:

$ sudo chmod 600 /etc/samba/server.credentials /etc/davfs2/secrets
$ sudo chown root:root /etc/samba/server.credentials /etc/davfs2/secrets

/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh – die gemeinsame Bibliothek, die alle anderen Skripte einbinden:

#!/bin/bash
log() {
    [[ "$DEBUG" == "1" ]] && logger -t "$LOG_TAG" -- "$1"
}

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

mount_with_retry() {
    local MOUNT="$1"
    local MAX_ATTEMPTS="${2:-3}"
    local SLEEP_SECONDS="${3:-2}"
    local MOUNT_TIMEOUT="${4:-10}"

    if mountpoint -q "$MOUNT"; then
        log "$MOUNT ist bereits eingehängt"
        return 0
    fi

    log "Hänge $MOUNT ein"

    local OUT ATTEMPT
    for ((ATTEMPT = 1; ATTEMPT <= MAX_ATTEMPTS; ATTEMPT++)); do
        if OUT=$(timeout "${MOUNT_TIMEOUT}s" mount "$MOUNT" 2>&1); then
            log "$MOUNT erfolgreich eingehängt"
            return 0
        fi
        log "Versuch $ATTEMPT/$MAX_ATTEMPTS für $MOUNT fehlgeschlagen (evtl. Timeout nach ${MOUNT_TIMEOUT}s): $OUT"
        [[ "$ATTEMPT" -lt "$MAX_ATTEMPTS" ]] && sleep "$SLEEP_SECONDS"
    done

    log "Alle Versuche für $MOUNT fehlgeschlagen"
    return 1
}

umount_with_fallback() {
    local MOUNT="$1"
    local TIMEOUT_SECONDS="${2:-5}"

    if ! mountpoint -q "$MOUNT"; then
        log "$MOUNT ist nicht eingehängt"
        return 0
    fi

    log "Hänge $MOUNT aus"

    if timeout "${TIMEOUT_SECONDS}s" umount "$MOUNT"; then
        log "$MOUNT erfolgreich ausgehängt"
        return 0
    fi

    log "Normaler Unmount von $MOUNT fehlgeschlagen, versuche Lazy Unmount"
    if umount -l "$MOUNT"; then
        log "$MOUNT per Lazy Unmount ausgehängt"
        return 0
    fi

    log "$MOUNT konnte nicht ausgehängt werden"
    return 1
}

/etc/NetworkManager/dispatcher.d/90-server-mount – Samba-Freigabe, gebunden an eine bestimmte WLAN-SSID oder ans Kabelnetz:

#!/bin/bash

DEBUG=1
LOG_TAG="server-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTS=(
    "/mnt/server/home"
    "/mnt/server/data"
)

mount_server() {
    if ! tcp_reachable server 445 2; then
        log "server auf Port 445 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    for MOUNT in "${MOUNTS[@]}"; do
        mount_with_retry "$MOUNT" 3 2 10
    done
}

umount_server() {
    for MOUNT in "${MOUNTS[@]}"; do
        umount_with_fallback "$MOUNT" 5
    done
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        if [[ "$IFACE" == wl* ]]; then
            SSID=$(nmcli -t -f active,ssid dev wifi |
                awk -F: '$1 == "yes" {print $2; exit}')

            log "Aktive WLAN-SSID: $SSID"

            if [[ "$SSID" == "MeinHeimnetz" ]]; then
                run_async mount_server
            fi

        elif [[ "$IFACE" == enp* || "$IFACE" == eth* ]]; then
            run_async mount_server
        fi
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mounts aushängen"
        umount_server
        ;;
esac

log "Dispatcher beendet"
exit 0

/etc/NetworkManager/dispatcher.d/90-webdav-mount – WebDAV-Freigabe, die einfach nur einen erreichbaren Cloud-Server voraussetzt:

#!/bin/bash

DEBUG=1
LOG_TAG="webdav-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTPOINT="/mnt/webdav"
HOST="cloud.example.com"

mount_webdav() {
    if ! tcp_reachable "$HOST" 443 3; then
        log "$HOST auf Port 443 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    mount_with_retry "$MOUNTPOINT" 3 2 10
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        run_async mount_webdav
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mount aushängen"
        umount_with_fallback "$MOUNTPOINT" 5
        ;;
esac

log "Dispatcher beendet"
exit 0

Für beide Skripte braucht ihr zusätzlich noch die passenden Symlinks, damit pre-down garantiert vor dem Verbindungsabbau feuert:

$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-server-mount \
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-server-mount
$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-webdav-mount \
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-webdav-mount

/usr/local/bin/mount-healthcheck.sh – das Sicherheitsnetz, das regelmäßig nachschaut:

#!/bin/bash
DEBUG=1
LOG_TAG="mount-healthcheck"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

log "Healthcheck gestartet"

SSID=$(nmcli -t -f active,ssid dev wifi 2>/dev/null |
    awk -F: '$1 == "yes" {print $2; exit}')

if [[ "$SSID" == "MeinHeimnetz" ]] || ping -c 1 -W 1 server >/dev/null 2>&1; then
    mount_with_retry "/mnt/server/home" 2 3
    mount_with_retry "/mnt/server/data" 2 3
else
    log "server im aktuellen Netz nicht erreichbar, überspringe"
fi

mount_with_retry "/mnt/webdav" 2 3

log "Healthcheck beendet"
exit 0

/etc/systemd/system/mount-healthcheck.service und mount-healthcheck.timer – Systemd-Einheiten, die das Healthcheck-Skript 60 Sekunden nach dem Boot und danach alle 10 Minuten anstoßen:

[Unit]
Description=Prueft und stellt Netzwerk-Mounts sicher
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
TimeoutStartSec=120
ExecStart=/usr/local/bin/mount-healthcheck.sh

[Unit]
Description=Fuehrt den Mount-Healthcheck 60s nach Boot und danach alle 10 Minuten aus

[Timer]
OnBootSec=60s
OnUnitActiveSec=10min
AccuracySec=30s

[Install]
WantedBy=timers.target

Aktivieren nicht vergessen:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now mount-healthcheck.timer

/usr/lib/systemd/system-sleep/90-cancel-network-mounts – optionales Sicherheitsnetz vor dem Suspend:

#!/bin/bash
case "$1/$2" in
    pre/*)
        logger -t sleep-mount-guard "Breche evtl. laufende Netzwerk-Mount-Versuche vor Suspend ab"
        pkill -9 -f 'mount\.cifs' 2>/dev/null
        pkill -9 -f 'mount\.davfs' 2>/dev/null
        ;;
esac

exit 0

Alle Skripte müssen ausführbar sein:

$ sudo chmod +x /etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh \
              /etc/NetworkManager/dispatcher.d/90-server-mount \
              /etc/NetworkManager/dispatcher.d/90-webdav-mount \
              /usr/local/bin/mount-healthcheck.sh \
              /usr/lib/systemd/system-sleep/90-cancel-network-mounts

Lange Reder, kurzer Sinn

Automatisches Einhängen von Netzwerkfreigaben über NetworkManager funktioniert gut, ist aber kein Fünf-Minuten-Job, wie es die Doku vermuten lässt. Wenn ihr nur den mount-Befehl in ein up-Skript packt, holt euch früher oder später eines der drei Probleme ein – meistens genau dann, wenn ihr unterwegs seid und kein Log zur Hand habt.

Mit _netdev, korrektem pre-down-Timing, asynchroner Ausführung und einem echten Erreichbarkeitstest vor jedem Mount seid ihr auf der sicheren Seite. Und das Muster lässt sich eins zu eins auf andere netzwerkabhängige Automatisierungen übertragen, etwa VPN-Verbindungen oder Backup-Jobs, die nur im richtigen Netz laufen sollen.

Schuld daran ist ein Update des offiziellen Linux-Clients auf Electron-Basis, das die GTK-Style-Window-Decoration durcheinandergebracht hat. Die Funktionalität von Spotify bleibt zwar unverändert, optisch sieht es aber alles andere als schick aus.

Lösungsmöglichkeiten für Spotify

Es gibt zwei einfache Wege, um das Problem zu beheben. Die bequemste Variante ist, Spotify als Flatpak zu installieren. Die Flatpak-Version zeigt den blauen Rahmen nicht und ihr müsst euch um nichts kümmern. Änderungen an der Konfiguration sind nicht nötig.

Falls ihr Spotify hingegen über den Spotify Launcher (Paket spotify-launcher aus den Extra-Quellen von Arch) oder direkt aus dem AUR (Eintrag spotify) installiert habt, müsst ihr das Start-Flag --ozone-platform=x11 setzen. Damit wird die GTK-Dekoration korrekt angezeigt. Je nach Installationsart fügt ihr das Flag wie folgt ein:

Für AUR-Spotify in der Datei ~/.config/spotify-flags.conf:

--ozone-platform=x11

Für Spotify Launcher in ~/.config/spotify-launcher.conf:

[spotify]
extra_arguments = ["--ozone-platform=x11"] 

Eventuell müsst ihr diese Dateien erst anlegen. Nach einem Neustart von Spotify sollte der blaue Rahmen verschwunden sein und alles wieder normal aussehen.

Korrektur von Fabian auf Mastodon: Das stimmt so nicht. Das ist ganz alleine dem geschulded das Spotify Wayland-nativ läuft und dort, unter GNOME, eine clientseitige Dekoration (CSD) braucht, die es über diese blaue bereit stellt. Das ganze wieder zu X11 zwingen schafft eventuell echte Probleme, wie verschwommene Schriften, schlechtes (kein) scaling und so weiter. Spotify ist auch nicht Elektron, sondern Chromium Embedded Framework (CEF).

Klar, es ist eine Krücke, aber eine die derzeit hilft. Die Änderung lässt sich ja auch schnell wieder rückgängig machen. Die anderen Optionen wären, Gnome unter X11 zu betreiben oder sich mit den blauen Rahmen anzufreunden. Beides in meinen Augen auch nicht gerade optimal. So ist es erstmal ein Workaround, den man natürlich nicht vergessen sollte, falls sich Spotify irgendwann einmal wieder komisch verhält.

Unter KDE ist das mit Spectacle und KSnip angenehm gelöst. In Kombination hat man mit den beiden Programmen zwei leistungsfähige Werkzeuge für Screenshots mit Anmerkungen, Schatten, Pfeilen, Transparenz und mehr. Unter GNOME sieht es – gerade unter Wayland – etwas magerer aus.

Früher habe ich oft Shutter verwendet. Das konnte alles, was ich gebraucht habe – bis auf Wayland. Seit der Umstellung auf das moderne Display-Server-Protokoll ist Shutter leider keine Option mehr. Die KDE-Tools funktionieren zwar mit Wayland, benötigen als Unterbau jedoch den KWin-Fenstermanager, da jeder Fenstermanager die Screenshot-Funktionen selbst implementieren muss. Hier kommt nun aber Gradia ins Spiel.

Einheitlicher Look für Screenshots

Gradia ist kein klassisches Screenshot-Werkzeug. Ihr könnt damit keine Bildschirmfotos aufnehmen – das übernimmt weiterhin das GNOME-eigene Screenshot-Tool (erreichbar per Druck-Taste, über das Anwendungsmenü oder per Shell-Erweiterung). Was Gradia bietet, ist eine unkomplizierte Nachbearbeitung: Ihr zieht ein bereits aufgenommenes Fensterbild hinein oder übernehmt es aus der Zwischenablage und Gradia poliert es optisch ein wenig auf.

Das funktioniert absolut simpel: Gradia erkennt automatisch den transparenten Fensterrand und legt einen Hintergrund mit Farbverlauf dahinter. Statt eines klassischen transparenten PNGs mit Schatten kommt ein Bild heraus, das sich auch auf dunklem oder hellem Hintergrund gut macht. Die abgerundeten Fensterecken lassen sich zusätzlich betonen, und ihr könnt den Abstand zum Bildrand individuell anpassen. So wirkt das Fenster im Screenshot „freigestellt“ und hebt sich besser vom Hintergrund ab.

Gradia gibt es als Flatpak und lässt sich bequem über Flathub installieren. Wer Flatpak noch nicht eingerichtet hat, findet auf Flathub selbst Anleitungen für so gut wie jede Linux-Distribution. Der unter der GPL-3.0 lizenzierte Quellcode von Gradia ist auf GitHub einsehbar. Die Versionsnummern wirken dort allerdings etwas uneinheitlich: Auf Flathub steht der Zähler bei Version 1.1.0, auf GitHub ist Version 0.2 die aktuellste, obwohl auch eine Version 0.3 existiert, die jedoch älter ist.

Kein Ersatz für Shutter – aber eine gute Ergänzung

Gradia ist klein, schnell installiert und macht genau eine Sache, die aber ordentlich. Wer unter GNOME arbeitet und ästhetische Screenshots für Veröffentlichungen im Netz oder auf Social Media braucht, bekommt mit Gradia ein praktisches Helferlein. Ich hoffe, dass das Tool noch etwas weiterentwickelt wird. Ein simples Annotationswerkzeug oder das Unkenntlichmachen von Bildbereichen wären zum Beispiel sinnvolle Ergänzungen. Aber auch so ist es ein nützliches Werkzeug im GNOME-Kosmos.

GNOME geht hier andere Wege und setzt auf moderne Schnittstellen für Hintergrunddienste. Doch viele Anwendungen – insbesondere proprietäre oder ältere Programme – verlassen sich weiterhin auf das Tray-Modell. Wer solche Tools nutzt, stößt schnell an Grenzen.

GNOME und der Verzicht auf das Legacy-Tray

Statt dem altbekannten Tray setzt GNOME auf moderne Konzepte, um Hintergrunddienste zugänglich zu machen. Dazu gehören:

• Benachrichtigungen im Message Tray: Anwendungen senden Hinweise über das Notification-System – ohne visuelle Präsenz in einem Icon.
• Hintergrunddienste im Systemmenü: Einige Apps (z. B. VPNs oder Bildschirmfreigaben) nutzen spezielle Schnittstellen, um sich direkt im Quick Settings-Menü zu verankern.
• Portale und systemd-User-Services: Anwendungen wie z. B. Syncthing oder Flatpak-Apps nutzen systemd oder D-Bus Portale, um unabhängig vom GUI-Session-Zustand zu laufen.

Diese Architektur ist aus GNOMEs Sicht technisch eleganter – doch viele von euch, die etwa Nextcloud, das TUXEDO Control Center oder andere klassische Apps nutzen, vermissen schlicht die kleinen Icons, die früher dezent im Panel hockten.

Die Lösung heißt AppIndicator – mit Haken

Genau hier kommt die GNOME-Shell-Erweiterung AppIndicator and KStatusNotifierItem Support ins Spiel. Sie bringt das „alte“ Tray zurück in die „neue““ GNOME-Welt – wenn auch nur als Workaround in Form einer Shell-Erweiterung. Optisch macht sie dabei deutlich mehr her als die offizielle Ersatzlösung Status Icons und integriert sich wesentlich besser ins moderne GNOME-Design.

Das Problem: Die Erweiterung wird von Canonical (Ubuntu) gepflegt, und ihre Weiterentwicklung verläuft oft schleppend. Nach jedem neuen GNOME-Release vergehen nicht selten Wochen oder sogar Monate, bis eine kompatible Version bereitsteht. Mit GNOME 48 war das erneut der Fall – doch diesmal gibt es gute Nachrichten.

News aus der Community: Patch für GNOME 48

Beim Stöbern im Issue-Tracker der Erweiterung bin ich auf einen spannenden Hinweis gestoßen: Für GNOME 48 existieren bereits funktionierende Patches! Und noch besser – unter Arch Linux sind diese bereits in das offizielle Paket eingeflossen.

Wenn ihr also Arch oder ein Arch-Derivat wie EndeavourOS oder Manjaro verwendet, könnt ihr euch die aktualisierte Version der Erweiterung direkt über pacman holen:

$ sudo pacman -S gnome-shell-extension-appindicator

Nach der Installation müsst ihr die alte Version der Erweiterung im Erweiterungs-Manager deaktivieren, euch ab- und wieder anmelden. Danach sollte die gepatchte Version als Systemerweiterung auftauchen – und ihr könnt AppIndicators unter GNOME 48 wieder nutzen.

Zwischen Moderne und Kompatibilität

Ich persönlich vermeide Tray-Icons, wo es geht. Viele freie Anwendungen bieten inzwischen native GNOME-Integrationen oder verzichten ganz auf den Zwang zur Hintergrundpräsenz. Doch wenn ihr auf ein Tool angewiesen seid, das nicht auf moderne GNOME-Techniken setzen, kommt ihr um die AppIndicator-Erweiterung kaum herum. Dank der aktiven Community – und dem Patch-Einbau unter Arch – funktioniert sie jetzt auch unter GNOME 48.

Früher habe ich für diese Aufgaben Shutter verwendet. Leider hat dieses Tool inzwischen den Support für Wayland verloren und scheint seit geraumer Zeit nicht weiterentwickelt zu werden. Als aktuelle Alternative setze ich deshalb KSnip ein, um Anmerkungen und Markierungen hinzuzufügen – Auch wenn ich dafür in den Kauf nehmen muss, dass ich mir damit einen Haufen Qt-Bibliotheken ins System laden muss. Was mir jedoch immer noch fehlt, ist ein Lupeneffekt, mit dem ich kleine Details in meinen Screenshots vergrößern und hervorheben kann.

Dieser Effekt lässt sich aber schnell und einfach mit GIMP umsetzen, auch wenn es dafür keinen direkten Filter gibt. In dieser Anleitung zeige ich euch, wie ihr in wenigen Minuten einen Lupeneffekt auf euren Screenshots erstellen könnt.

Schritt-für-Schritt-Anleitung für den Lupeneffekt in GIMP

Screenshot öffnen

Öffnet zunächst euren Screenshot in GIMP. Falls ihr noch keinen Screenshot gemacht habt, könnt ihr dies direkt in GIMP erledigen: Wählt dafür im Menü Datei | Erstellen | Screenshot. Damit könnt ihr den Screenshot entweder direkt im Programm aufnehmen oder eine vorherige Aufnahme importieren.

Bereich auswählen

Wählt nun das Rechteckige Auswahlwerkzeug oder das Elliptische Auswahlwerkzeug aus der linken Werkzeugleiste aus. Zieht die Auswahl um den Bereich, den ihr vergrößern wollt – also den Bereich, den ihr später als Lupeneffekt hervorheben möchtet. Um mit dem Ellipsenwerkzeug einen kreisförmige Auswahl zu erstellen, haltet ihr während des Aufziehens mit der Maus die Umschalt-Taste gedrückt.

Sobald die Auswahl getroffen ist, drückt auf der Tastatur Strg+C, um den Bereich zu kopieren. Anschließend drückt Strg+V, um den Bereich als neue schwebende Auswahl einzufügen. Diese neue Auswahl erscheint dann im rechten oberen Bereich von GIMP unter Schwebende Ebene. Klickt mit der rechten Maustaste darauf und wählt Zur neuen Ebene aus, um die schwebende Auswahl in eine feste Ebene mit dem Namen Transformation umzuwandeln.

Vergrößern der Auswahl

Jetzt kommt der eigentliche Lupeneffekt: Wählt das Skalieren-Werkzeug aus der linken Werkzeugleiste aus und klickt auf die gerade erstellte neue Ebene. Vergrößert die Auswahl so, dass sie die gewünschte „Lupenwirkung“ erzielt. Achten dabei darauf, das Seitenverhältnis zu sperren, damit die Proportionen der Auswahl erhalten bleiben.

Ebene an Bildgröße anpassen

Rechtsklickt auf die neue Ebene im rechten Panel und wählt Ebenen auf Bildgröße. Damit passt ihr die Ebene an die Gesamtbildgröße an, ohne dass sich die anderen Elemente auf dem Screenshot verändern.

Auswahl um den Effekt hinzufügen

Rechtsklickt wieder auf die Ebene im rechten Panel und wählt diesmal Auswahl aus Alphakanal aus. Diese Funktion macht den transparenten Bereich der Ebene auswählbar.

Kontur hinzufügen

Geht nun auf Bearbeiten | Auswahl nachziehen … und passt die Eigenschaften der Umrahmung an. Ihr könnt hier die Farbe der Linie und deren Dicke wählen. Die Standardfarbe wird dabei aus der Vordergrundfarbe von GIMP übernommen. Eine Vorschau gibt es für diese Funktion leider nicht. Klickt auf OK, um die Umrahmung anzuwenden.

Hintergrund anpassen

Zu guter Letzt könnt ihr noch einen Filter auf den Hintergrund anwenden, um den Effekt weiter zu verstärken. Eine Unschärfe oder ein Schatten auf der neuen Ebene sorgen dafür, dass der Lupeneffekt stärker zur Geltung kommt. Dazu könnt ihr im rechten Panel der Ebene Filter auswählen und verschiedene Optionen ausprobieren, wie z. B. Weichzeichnen oder Schatten hinzufügen.

[td_smart_list_end]

Mit diesen einfachen Schritten habt ihr einen effektiven Lupeneffekt in GIMP erstellt. Es erfordert ein bisschen Übung und Feintuning, aber schon nach wenigen Versuchen bekommt ihr ein gutes Gefühl für die Werkzeuge und könnt sie effizient in eure Screenshot-Nachbearbeitung einbauen. Besonders praktisch: Ihr könnt die Methode für beliebige Bildbereiche anwenden, um nicht nur Text, sondern auch andere Details in euren Screenshots hervorzuheben.

Falls ihr also gerade überlegt, von Google Chrome auf Firefox zu wechseln, oder diesen Schritt vielleicht schon gemacht habt: Willkommen! Ihr habt euch für einen starken, flexiblen und offenen Browser entschieden. Aber vielleicht habt ihr auch schon gemerkt – ganz reibungslos läuft der Umstieg vielleicht nicht. Ich lese beispielsweise immer wieder, dass es besonders bei YouTube stockt: Videos starten langsam, ruckeln, laufen nur in niedriger Qualität oder verursachen eine ungewöhnlich hohe CPU-Last.

Woran liegt das? Nun, ganz unbegründet sind die Spekulationen nicht, dass Google als Betreiber von YouTube und als wohl erfolgreichster Werbekonzern aller Zeiten wenig Interesse daran hat, Firefox-Nutzer mit der gleichen Sorgfalt zu behandeln wie Chrome-User. Immerhin ist Firefox die letzte ernstzunehmende Konkurrenz im Browsermarkt. Doch zum Glück lässt sich mit ein paar gezielten Einstellungen einiges retten.

YouTube unter Firefox – diese Tipps helfen

uBlock Origin installieren

Ein zuverlässiger Werbeblocker gehört heute zur Grundausstattung. Nicht nur, weil er lästige Werbung entfernt, sondern auch, weil er Tracking und andere ressourcenhungrige Scripte blockiert. Die Empfehlung kann hier nur lauten: uBlock Origin. Das Add-on ist quelloffen, sehr performant und lässt sich präzise konfigurieren. Um im Gegensatz zu Chrome, gibt es uBlock Origin noch in der „Vollversion“ und nicht nur als abgespeckte Lite-Alternative. Nach der Installation empfiehlt es sich, unter den Filterlisten zusätzlich den Filter uBlock filters – Annoyances zu aktivieren. Dieser sorgt dafür, dass auch störende Seitenelemente (etwa Cookie-Banner, Overlay-Effekte oder YouTube-Spielereien) ausgeblendet werden. Behaltet allerdings im Hinterkopf, dass dieser Filter aktiv ist, er sorgt auf manchen Webseiten auch zu unerwünschten Aussetzern.

Ambient Mode bei YouTube deaktivieren

YouTube hat vor einiger Zeit den sogenannten Ambient Mode eingeführt – dabei werden Farbverläufe des Videos weich in den Hintergrund projiziert. Ganz so, als ob über die Köpfe der Kinobesucher hinweg ein Projekt das Bild auf eine Leinwand werfen würde. Das sieht zwar nett aus, sorgt unter Firefox wohl aber häufig für Darstellungsfehler oder spürbare Performance-Einbußen. Zwingend nötig ist der Effekt nun wirklich nicht.

Wenn euch dieser Effekt auffällt (wie z. B. in diesem Beispielvideo), könnt ihr über das Zahnradsymbol und den Menüpunkt Beleuchtung wie im Kino abstellen. Aber meist ist diese Einstellung nicht von Dauer. Stattdessen bietet es sich an, ihn mithilfe von uBlock Origin gezielt entfernen. Tragt dazu unter Meine Filter folgenden Eintrag ein:

youtube.com###cinematics.ytd-watch-flexy:remove()

Setzt dann noch den Haken oben bei Eigene Filter aktivieren. Das entfernt das störende Element zuverlässig – und senkt ganz nebenbei die Systemlast beim Abspielen von Videos.

Enhanced-h264ify nutzen

Ein echter Gamechanger kann das Add-on enhanced-h264ify sein. Damit zwingt ihr YouTube dazu, Videos im älteren H.264-Format abzuspielen – statt in den modernen VP8- oder VP9-Codecs, die oft hardwareseitig nicht unterstützt werden. Gerade unter Linux – oder bei Laptops ohne aktuelle GPU-Beschleunigung – läuft H.264 oft wesentlich flüssiger. Weniger CPU-Last, weniger Ruckler, längere Akkulaufzeit. Nach der Installation lässt sich das Verhalten in den Einstellungen des Add-ons fein abstimmen.

User-Agent anpassen (optional)

Wenn trotz aller Optimierungen YouTube weiterhin zickt, kann es helfen, den sogenannten User-Agent zu ändern. Damit gebt ihr euch gegenüber Webseiten nicht mehr als Firefox, sondern z. B. als Chrome-Browser aus. Das geht ganz einfach mit dem Add-on User-Agent Switcher. Nach der Installation könnt ihr den Browser auf Chrome „umstellen“. Klar: Ideal ist das nicht. Denn so bekommen Webseitenbetreiber keine Rückmeldung, dass Firefox-Nutzer existieren und gute Performance erwarten. Aber wenn ihr nur schauen wollt – und euch der Ärger mit YouTube nervt – kann dieser Schritt kurzfristig helfen.

Die Browser-Wars sind zurück

Was wir gerade erleben, ist kein Zufall. Firefox steht allein gegen eine überwältigende Übermacht an Chrome-Derivaten. Ob Brave, Microsofts Edge, Opera oder Vivaldi – sie alle bauen inzwischen auf Googles Blink-Engine auf. Firefox ist der leider letzte große Browser mit echter technischer Unabhängigkeit. Wir können nun wirklich nur hoffen, dass Mozilla trotz aller Querelen weiterhin wirtschaftlich stabil bleibt und die Entwicklung des Browser vorran treibt.

Und genau deshalb ist es so wichtig, ihn zu nutzen. Ihn zu unterstützen. Denn ohne Firefox würde Google das Web wohl endgültig kontrollieren. Der Kampf um offene Standards, freie Software und ein privatsphärefreundliches Internet ist zurück – und wir alle sind ein Teil davon. Also: Wechselt. Testet. Gebt Firefox eine echte Chance. Und lasst euch nicht vom ersten YouTube-Ruckler entmutigen. Wenn ihr noch weitere Tipps oder Erfahrungen zum Thema habt, schreibt sie gerne in die Kommentare.

Besonders ärgerlich wird das, wenn der Monitor, den GDM für den Login verwendet, gar nicht eingeschaltet ist. Dann bleibt der Bildschirm schwarz, und ich tappe im Dunkeln, bis ich das Notebook aufklappe oder den richtigen Monitor finde. Offenbar nutzt GDM eine eigene Konfiguration, die nichts mit den Anzeigeeinstellungen der GNOME-Sitzung zu tun hat. Im Wiki von Arch Linux bin ich auf eine Lösung gestoßen, mit der sich dieses Verhalten zuverlässig korrigieren lässt – und die auch unter anderen Distributionen funktioniert.

Warum GDM den falschen Monitor verwendet

Das Problem tritt typischerweise bei Systemen mit mehreren Bildschirmen auf, besonders wenn proprietäre Grafiktreiber wie von Nvidia im Einsatz sind. GNOME speichert die Bildschirmanordnung pro Nutzer in einer Datei namens monitors.xml im Verzeichnis ~/.config. GDM hingegen nutzt eine eigene Konfiguration im Kontext des gdm-Benutzers. Da diese Datei beim Einrichten des Systems nicht automatisch mit der des Hauptbenutzers synchronisiert wird, kann es passieren, dass der Login-Screen auf dem falschen Bildschirm erscheint – und dort auch bleibt.

Manuelle Lösung: Anzeigeeinstellungen übernehmen

Der einfachste Weg, GDM die richtige Monitorkonfiguration beizubringen, ist das Kopieren der monitors.xml-Datei aus dem Benutzerverzeichnis in das Konfigurationsverzeichnis von GDM.

1. Stellt zunächst die gewünschte Bildschirmkonfiguration in GNOME ein. Öffnet dazu die Anzeigeeinstellungen über:

$ gnome-control-center display

Wählt den bevorzugten Hauptbildschirm aus und arrangiert die Monitore nach Wunsch. Die Änderungen werden automatisch in eurem Homeverzeichnis unter ~/.config/monitors.xml gespeichert.

2. Kopiert die Datei in das Home-Verzeichnis von GDM:

$ sudo install -o root -m 644 ~/.config/monitors.xml ~gdm/.config/

Das Home-Verzeichnis des GDM-Nutzers ~gdm wird dabei korrekt vom System interpretiert.

3. Startet GDM neu, damit die neue Konfiguration übernommen wird – Achtung: Dabei wird eure aktuelle GNOME-Sitzung ohne Vorwarnung beendet:

$ sudo systemctl restart gdm

Nach dem Neustart sollte der Login-Screen auf dem gewünschten Monitor erscheinen.

Automatisierte Lösung: Mit einem Systemd-Service

Wenn Ihr häufiger mit unterschiedlichen Monitor-Setups arbeitet oder einfach eine dauerhafte Lösung bevorzugt, könnt Ihr das Kopieren der Datei beim Systemstart automatisieren.

1. Legt das Verzeichnis für den systemd-Override an:

$ sudo mkdir -p /etc/systemd/system/gdm.service.d

2. Erstellt eine neue Konfigurationsdatei override.conf mit folgendem Inhalt:

[Service]
ExecStartPre=/bin/sh -c 'install -o root -m 644 /home/EUER_NUTZER/.config/monitors.xml ~gdm/.config/monitors.xml || true'

Ersetzt EUER_NUTZER durch euren tatsächlichen Benutzernamen.

3. Ladet die systemd-Konfiguration neu:

$ sudo systemctl daemon-reexec

Beim nächsten Start von GDM wird die Datei automatisch übernommen.

Noch einfacher: Mit den grafischen GDM-Settings

Ganz zum Schluss gibt es noch eine grafische Alternative. Mit dem Programm GDM Settings, oder in der deutschen Übersetzung GDM Einstellungen, könnt Ihr viele Details des Loginmanagers konfigurieren – darunter eben auch die Bildschirmeinstellungen übernehmen. Ganz einfach per Mausklick und ohne Kommandozeile.

Das Programm ist kein offizielles GNOME-Tool und befindet sich meist auch nicht in den Paketquellen. Ihr könnt es aber via Flathub problemlos installieren. Achtet beim ersten Start auf die Warnung: Nutzung auf eigene Gefahr. Viele Optionen ändern Systemdateien, was im Einzelfall zu Problemen führen kann – aber in der Regel funktioniert alles wie gewünscht.

Zum Übernehmen der Bildschirmkonfiguration des aktuell angemeldeten Nutzers öffnet Ihr in der Seitenleiste den Punkt Anzeige und klickt dann auf Aktuelle Bildschirmeinstellungen anwenden. Eine automatische Übernahme bei wechselnden Setups gibt es hier allerdings nicht. Wenn Ihr euer Notebook regelmäßig zwischen Arbeitsplatz und Homeoffice mit jeweils unterschiedlicher Monitorkonfiguration nutzt, ist die oben beschriebene systemd-Variante möglicherweise die bessere Wahl.

Ursache ist die Audioerkennung des GNOME-Settings-Daemons, der in bestimmten Fällen nicht automatisch zwischen Headset und einfachem Kopfhörer unterscheiden kann. Eine integrierte Option zur dauerhaften Deaktivierung des Dialogs existiert bislang nicht. Eine Erweiterung schafft hier Abhilfe.

Eine einfache Lösung: Auto Select Headset

Die GNOME-Erweiterung Auto Select Headset unterdrückt den „Select Audio Device“-Dialog auf Systemen ohne automatische Klinkenerkennung. Stattdessen wird dem System direkt mitgeteilt, dass ein Headset angeschlossen wurde. Die Erweiterung eignet sich für alle, die eine automatische Auswahl des Audio-Geräts bevorzugen und dabei auf zusätzliche Rückfragen verzichten möchten. Der Quellcode ist auf GitHub verfügbar.

Das Logo des Herstellers glitzert mir auf der Frontseite des Gehäuses entgegen, doch weitere Informationen zum Gerät finden sich dort nicht. Und auch auf der Rückseite gibt es keine weiteren Details. Ein Schildchen mit der Typenbezeichnung gab es in der Regel bei den guten alten Röhrenmonitoren, doch bei meinen aktuellen Dell-Flatscreens findet sich dort nichts mehr. Auch die Monitor-Einstellungen der Gnome-Desktopumgebung lässt den Nutzer im Stich. Die zeigen nur dann Informationen zum Typ des Monitors an, wenn zwei Displays angeschlossen sind. Mehr als den Hersteller und die Bildschirmdiagonale erfährt man jedoch nicht.

Gnome geizt mit Informationen

Wenn die grafischen Tools so sparsam mit Informationen sind, dann hilft doch sicherlich das Terminal. Tools zur Anzeige von Hardware-Informationen gibt es unter Linux ja wie Sand am Meer, da müsste doch was dabei sein. Das Go-To-Werkzeug für diese Aufgabe wäre hier Inxi, das sich bei vielen Distributionen aus den Paketquellen installieren lässt (etwa via pacman -S inxi bei Arch Linux oder apt install inxi bei Ubuntu, Debian und Derivaten). Das Kommando inxi -F spuckt dann sämtliche Details zum System aus, aber auch hier Pustekuchen: keine Details zu den angeschlossenen Monitoren.

Details zum Monitor über das Terminal

Um mir eine weitere Suche unter den zahlreichen Tools zu ersparen, greife ich nun gleich auf das „richtige“ Werkzeug zurück. Details zum Displayserver liefert das Kommandozeilenwerkzeug Xrandr. Tools wie Inxi machen in der Regel nichts anderes, also solche Kommandos auszuführen und die Ausgabe optisch aufgewertet anzuzeigen. Über xrandr -q --verbose bekommt man also zahlreiche Details zu den unterstützten Auflösungen und Wiederholraten, doch der Name und Typ des Monitors fehlt immer noch. Aber nicht ganz: Die Daten sind im Feld EDID oder Extended Display Identification Data codiert.

Wer diese Daten nun jetzt nicht von Hand decodieren möchte, muss sich ein wenig unter die Arme greifen lassen. Das bei Stack Overflow gepostete Skript beispielsweise braucht keine weiteren Helferlein, um die EDID zu dekodieren. Ihr speichert folgenden Code einfach als monitor.sh ab und macht die Skriptdatei via chmod +x monitor.sh ausführbar. Aus dem Terminal heraus aufgerufen, zeigt das Skript dann die angeschlossenen Monitore inklusive den Namen des Herstellers und der Typenbezeichnung an. Technische Details zu Auflösungen oder Wiederholraten fehlen, doch die lassen sich ja auch an zahlreichen anderen Stellen ermitteln.

#!/bin/bash
while read -r output hex conn; do
    [[ -z "$conn" ]] && conn=${output%%-*}
    echo "# $output $conn   $(xxd -r -p <<< "$hex")"
done < <(xrandr --prop | awk '
    !/^[ \t]/ {
        if (output && hex) print output, hex, conn
        output=$1
        hex=""
    }
    /ConnectorType:/ {conn=$2}
    /[:.]/ && h {
        sub(/.*000000fc00/, "", hex)
        hex = substr(hex, 0, 26) "0a"
        sub(/0a.*/, "", hex)
        h=0
    }
    h {sub(/[ \t]+/, ""); hex = hex $0}
    /EDID.*:/ {h=1}
    END {if (output && hex) print output, hex, conn}
    ' | sort
)

$ ./monitor.sh 
# DP1-8 DP1   DELL U2515H
# HDMI1 HDMI1   DELL P2213

Alternativ holt ihr euch das Paket edid-decode auf den Rechner. Bei Ubuntu/Debian oder Linux Mint direkt über die offiziellen Paketquellen (via apt install edid-decode), bei Arch Linux oder Manjaro lediglich über das AUR (etwa mit einem AUR-Helper via yay -S edid-decode-git). Hier genügt dann der folgende Einzeiler, der allerdings nicht mit dem proprietären Nvidia-Treiber funktioniert. Hier bekommt ihr dann allerdings nicht nur den Hersteller und den Monitortyp angezeigt, sondern auch gleich die Seriennummer der Geräte — falls ihr an diesen Interesse haben solltet.

$ for file in $(ls -1 /sys/class/drm/*/edid); do text=$(tr -d 0 <"$file"); if [ -n "$text" ]; then edid-decode "$file" | grep -e Manufacturer: -e Product; sleep 0.0001; fi done
  Vendor & Product Identification:
    Manufacturer: DEL
    Display Product Serial Number: '9X2VY55I0J0L'
    Display Product Name: 'DELL U2515H'
  Vendor & Product Identification:
    Manufacturer: DEL
    Display Product Serial Number: 'Y57VF31AAT3M'
    Display Product Name: 'DELL P2213'

Letztendlich wäre es natürlich schneller gewesen die alten Rechnungen herauszusuchen, oder vielleicht auch mal einen Blick über den Tellerrand zu KDE zu werfen. Im Gegensatz zu den Einstellungen von Gnome zeigen die Systemeinstellungen von KDE nämlich gleich die Bildschirmkennungen mit an. Wie immer ist Gnome ein wenig arg spartanisch und geizig mit Funktionen und Details. In meinen Augen dürften die System-Settings von Gnome ruhig auch die Bezeichnungen ausgeben. Nötig sind sie in der Regel nicht, doch ab und an können sie doch auch praktisch sein.

Es gibt aber durchaus ein paar Erweiterungen, die ich nicht missen möchte: Dazu gehört zum Beispiel GSConnect zum Andocken des Desktops an KDE Connect, sodass Benachrichtigungen des Handys an den Desktop weitergeleitet werden oder die Musikwiedergabe automatisch stoppt, sobald ein Anruf eingeht. Der Abgleich der Zwischenablage für Copy&Paste ist auch praktisch. Aus Nostalgiegründen gehört aber aktuell auch der Desktop Cube dazu. Die Erweiterung ergänzt Gnome mit einem 3D-Würfel, wie ihr ihn eventuell noch von Compiz her kennt — einen Rechner mit schneller Grafikkarte braucht es dafür nicht zwingend. Bei mir genügt ein Intel Core i7-7700T mit einer internen HD Graphics 630. An der Erweiterung wird auf Github aktuell aktiv gearbeitet, die fünfte Version des Addons wurde gerade erst vor zwei Tagen veröffentlicht. Neu ist ein einfacher Dialog zur Konfiguration der wichtigsten Parameter, sodass ihr den Würfel an eure eigenen Vorstellungen anpassen könnt.