Dominic Böttger

← Zurück zum Blog

Microsoft Teams auf Omarchy als richtige Chromium-PWA optimieren

Veröffentlicht am 18. April 2026 von Dominic Böttger (heute) · 5 Min. Lesezeit

Microsoft liefert keinen nativen Teams-Client für Linux mehr aus. Auf Omarchy – also Arch mit Hyprland – ist die beste Lösung Teams als Chromium Progressive Web App. Richtig eingerichtet verbraucht das weniger RAM als der alte Electron-Client, erkennt Kamera und Screen korrekt und bleibt an das Arbeitsprofil gebunden, das man wirklich nutzen will.

Dieser Beitrag beschreibt das Setup, auf das ich nach einigem Feinschliff gekommen bin: eine echt installierte PWA, gestartet aus einem eigenen .desktop-Eintrag in ein bestimmtes Chromium-Profil, mit Wayland-Screen-Capture und VA-API-Hardwaredecodierung und -encoding für AMD oder Intel.

Das Problem mit dem Standard-Launcher

Omarchys Helferskript omarchy-launch-webapp startet Chromium mit --app=<URL>. Das ergibt ein Fensterlose-Chrome-Fenster – aber:

  • Es wählt kein Chromium-Profil aus; Teams hängt sich an das Profil, das gerade aktiv ist.
  • Es ist keine registrierte PWA – die Fensteridentität (StartupWMClass) fällt auf die generische Klasse chromium zurück, und Flags wie --app-id= können das Fenster nicht ansteuern.
  • Flags wie --app-id= greifen nicht, weil im Web-App-Register von Chromium kein Manifest existiert.

Die saubere Lösung: Teams einmal als echte PWA installieren und den .desktop-Eintrag auf deren App-ID zeigen lassen.

Schritt 1: Teams als echte PWA installieren

  1. Chromium in dem Profil öffnen, an das Teams gebunden werden soll (bei mir ist das Default, mit Anzeigenamen Work).
  2. https://teams.microsoft.com aufrufen und einloggen.
  3. In der Adressleiste auf das Install-Symbol klicken (oder Menü → Übertragen, speichern, teilen → Teams installieren).

Chromium schreibt nun ein Manifest unter ~/.config/chromium/<Profile>/Web Applications/Manifest Resources/<app-id>/ und legt einen automatisch generierten Launcher unter ~/.local/share/applications/chrome-<app-id>-Default.desktop an. Die ID auslesen:

ls ~/.config/chromium/Default/Web\ Applications/Manifest\ Resources/

Bei mir kam ompifgpmddkgmclendfeacglnodjjndh heraus. Bei dir kann es abweichen, weil die ID aus der Manifest-URL und dem Profil abgeleitet wird.

Schritt 2: Einen stabilen .desktop-Eintrag auf die PWA zeigen

Omarchys eigener Teams.desktop liegt unter ~/.local/share/applications/Teams.desktop. Die Exec-Zeile so ersetzen, dass sie omarchy-launch-webapp umgeht und Chromium direkt startet – mit fixem Profil und der PWA über ihre App-ID:

[Desktop Entry]
Version=1.0
Name=Teams
Comment=Teams
Exec=/usr/bin/chromium --profile-directory=Default --app-id=ompifgpmddkgmclendfeacglnodjjndh
Terminal=false
Type=Application
Icon=/home/you/.local/share/applications/icons/Teams.png
StartupNotify=true
StartupWMClass=chrome-ompifgpmddkgmclendfeacglnodjjndh-Default

Zwei Details sind wichtig:

  • --profile-directory=Default erzwingt das Work-Profil unabhängig davon, was Chromium sonst gerade macht. Die Profilnamen aus ~/.config/chromium/Local State heißen Default, Profile 1 usw.; gemeint ist der Ordnername, nicht der Anzeigename.
  • StartupWMClass=chrome-<app-id>-<profile> ist die Fensterklasse, die der Compositor tatsächlich meldet (prüfbar via hyprctl clients). Chromiums eigener auto-generierter Launcher verwendet stattdessen crx_<app-id> – ein Überbleibsel aus X11-Zeiten; unter Wayland trägt die echte Klasse den Profil-Suffix. Mit dem passenden Wert erkennen Walkers Startup-Benachrichtigung, jeder Fenster-Switcher und spätere Automation die PWA als eigenständige App statt als generisches chromium-Fenster.

Den doppelten, automatisch erzeugten Chromium-Launcher ausblenden, damit der App-Launcher nur deinen Eintrag anzeigt:

sed -i '/^Name=Microsoft Teams (PWA)/a NoDisplay=true' \
  ~/.local/share/applications/chrome-ompifgpmddkgmclendfeacglnodjjndh-Default.desktop
update-desktop-database ~/.local/share/applications

Schritt 3: VA-API-Treiber für Hardware-Video installieren

Videoanrufe fressen CPU, solange Chromium Decoding und Encoding nicht auf die GPU auslagern kann. Unter Arch braucht es libva und den passenden Treiber:

# AMD (Radeon 880M / 890M etc.)
sudo pacman -S --needed libva libva-mesa-driver libva-utils

# Intel (moderne iGPUs)
sudo pacman -S --needed libva intel-media-driver libva-utils

Prüfen:

vainfo

Die Ausgabe sollte VAProfileH264* mit sowohl VAEntrypointVLD (Decoder) als auch VAEntrypointEncSlice (Encoder) enthalten. Ideal ist zusätzlich VP9Profile0, weil Teams in neueren Builds VP9 aushandelt.

Schritt 4: Chromium-Flags für Wayland und Teams

Diese Zeilen gehören in ~/.config/chromium-flags.conf (Chromium unter Arch liest die Datei beim Start):

--ozone-platform=wayland
--ozone-platform-hint=wayland
--enable-features=TouchpadOverscrollHistoryNavigation,WebRTCPipeWireCapturer,VaapiVideoDecodeLinuxGL,VaapiVideoEncoder
--ignore-gpu-blocklist
--enable-zero-copy

Was jede Zeile bringt:

  • --ozone-platform=wayland / --ozone-platform-hint=wayland: nativ auf Wayland laufen. Keine XWayland-Umleitung, sauberes HiDPI, korrekte Mauszeiger-Skalierung.
  • WebRTCPipeWireCapturer: nutzt das PipeWire-Portal für Screen Sharing. Ohne diese Flag versucht Chromium X11-Fenster zu greifen und der Share-Dialog bleibt leer.
  • VaapiVideoDecodeLinuxGL / VaapiVideoEncoder: hängt Chromiums WebRTC-Pipeline an VA-API für H.264-, HEVC-, VP9- und AV1-Decoding und -Encoding.
  • --ignore-gpu-blocklist: umgeht die konservative Treiber-Blocklist, die einige funktionierende Setups nach wie vor ablehnt.
  • --enable-zero-copy: spart eine zusätzliche Framekopie zwischen Decoder und Compositor – besonders auf iGPUs spürbar.

Chromium danach komplett neu starten (pkill -x chromium und neu öffnen – Flags werden nur beim Start gelesen).

Schritt 5: Stack überprüfen

In einem normalen Chromium-Fenster chrome://gpu öffnen und prüfen:

  • Video Decode und Video Encode: beide sollten Hardware accelerated anzeigen.
  • WebRTC: der PipeWire-Capturer muss auftauchen.
  • Compositing: hardwarebeschleunigt, Vulkan- oder OpenGL-Backend.

Danach Teams aus Walker starten, ein Meeting beitreten und nvtop oder radeontop laufen lassen. Während eines Anrufs sollten Decoder- und Encoder-Einheiten auf der GPU arbeiten, die CPU bleibt niedrig. Auf meiner AMD 890M fällt die Last mit eingeschalteter Kamera von ca. 35 % CPU auf etwa 12 %, sobald VA-API aktiv ist.

Warum sich der Aufwand lohnt

Teams als vollwertige PWA statt als URL-Shortcut zu behandeln bringt drei Gewinne gleichzeitig:

  1. Jedes Mal das richtige Profil – kein versehentlicher Post im falschen Tenant mehr, weil Chromium das zuletzt genutzte Profil erwischt hat.
  2. Stabile Fensteridentitäthyprctl clients meldet eine vorhersagbare Klasse, sodass spätere Automation oder App-spezifische Regeln etwas Verlässliches zum Matchen haben. (Zu beachten: mako zeigt Benachrichtigungen trotzdem als Chromium an – Chromium reicht den PWA-Namen nicht an den Notification-Daemon weiter.)
  3. Echte Hardwarebeschleunigung – halbe CPU-Last und ein deutlich kühlerer Laptop in langen Meetings.

Das komplette Setup sind weniger als zwanzig Zeilen Konfiguration, wenn man weiß, welche es sein müssen.

Geschrieben von Dominic Böttger

← Zurück zum Blog

Kommentare werden über GitHub Discussions bereitgestellt. Zum Kommentieren wird ein GitHub-Konto benötigt.

Aktuelle Blogbeiträge