Screen sharing in Google Meet, Zoom and Teams on Omarchy

Video calls are the first thing most people test after switching, and on Omarchy they mostly just work. This page is checked against 4.0.4 (2026-09-15). Where behaviour differs from 3.x, it says so.

How sharing actually works here

There is no Google Meet client, no Zoom client and no Teams client on Omarchy. All three run in a browser, and the Zoom entry you get out of the box is a Chromium web app wrapper: Zoom.desktop runs omarchy-webapp-handler-zoom, which turns a zoommtg:// or zoomus:// link into a https://app.zoom.us/wc/join/... URL and opens it frameless. The Web Apps manual chapter covers that side.

Because everything runs under Wayland, the browser does not draw its own source list. It calls xdg-desktop-portal-hyprland, which Omarchy installs as a base package, and the portal opens a picker window. So when Meet says to choose what to share, the window that appears is not part of Chromium. It is hyprland-preview-share-picker, wired up in ~/.config/hypr/xdph.conf:

screencopy {
    allow_token_by_default = true
    custom_picker_binary = hyprland-preview-share-picker
}

The picker has three tabs. Outputs is the default page and covers whole monitors. Windows lists live previews of every open window, one click to pick. Region runs slurp so you can drag a rectangle. Its settings live in ~/.config/hyprland-preview-share-picker/config.yaml if you want bigger previews or a different default tab.

One thing that trips up people following old guides: because allow_token_by_default is on and the picker sets hide_token_restore: true, the restore token is already granted for you. Advice from 2025 about ticking a box to allow a restore token so Meet stops asking on every share, which is how a contributor on #1862 solved it on 3.0.x, no longer applies: the box is hidden and the token is granted. xdph.conf is identical in 3.8.4 and in 4.0.4.

xdph.conf is read by the portal, not by Hyprland, so hyprctl reload does nothing to it. Changes land when the portal restarts, which normally means your next login.

Verify it worked

echo "$XDG_CURRENT_DESKTOP"                      # must print Hyprland
pacman -Qs hyprland-preview-share-picker
systemctl --user status xdg-desktop-portal-hyprland --no-pager

XDG_CURRENT_DESKTOP is set to Hyprland in Omarchy’s envs.lua specifically so the portal picks the right backend. If it prints something else, a custom session or a launcher is overriding it, and the portal may not select the Hyprland backend at all.

The sharing bar you cannot dismiss

Chromium shows a floating bar reading something like “meet.google.com is sharing your screen”. Its Hide button does nothing under Wayland, so the bar parks itself in the middle of your screen. That is issue #1862, still open, and issue #5373, closed.

Omarchy has shipped a fix since commit 35650a6 on 2026-04-22, which landed in v3.6.0. On 4.x it lives in the Lua config as a window rule that throws that window onto a silent special workspace. If the bar is still in your face:

1. Check that the rule is loading.

hyprctl clients | grep -i -A2 "is sharing"

2. If the window exists on a normal workspace, its title probably did not match. The shipped rule matches the English string, so a browser running in another language slips through. Add your own rule with the wording your browser uses to ~/.config/hypr/hyprland.lua:

o.window({ title = ".*compartiendo.*" }, { workspace = "special silent" })

3. Reload and retest.

hyprctl reload && hyprctl configerrors

On 3.x the same rule was a windowrule = workspace special silent, match:title .*is sharing.* line in ~/.local/share/omarchy/default/hypr/apps/browser.conf, sourced from the defaults rather than from your own config. On 4.x it only loads if your ~/.config/hypr/hyprland.lua still carries the require("default.hypr.omarchy") line. If a hand edited config lost it, omarchy refresh hyprland restores the defaults.

A monitor is missing from the picker

The Outputs tab lays monitor cards out starting at coordinate 0,0. If your Hyprland monitor layout has every output at a positive offset, which is easy to end up with after dragging displays around, the cards are drawn outside the visible window and the picker looks like it has fewer monitors than you do. Issue #11221 documents this in detail and ties it to an upstream bug that was fixed on 2026-08-24, upstream issues 15 and 24, both now closed. The hyprland-preview-share-picker package Omarchy installs is 0.2.1-1, built in December 2025, and the -git variant is pinned to a commit from the same month, so the fix has not reached you on 4.0.4. Issue #10057 looks like the same symptom.

Two workarounds:

1. Move your layout in ~/.config/hypr/monitors.lua so one output has position 0x0, and shift the others by the same amount so nothing overlaps.
2. Or skip the Outputs tab. The Windows tab and the Region tab do not use that layout maths, so they still list everything.

Glitching and artifacts once you start sharing

Issue #10496 reports the browser filling with rendering artifacts in Meet when you start sharing while someone else is already sharing, on a hybrid Intel plus NVIDIA laptop. The likely root cause is issue #9890: default/hypr/nvidia.lua exports LIBVA_DRIVER_NAME=nvidia whenever an NVIDIA GPU with GSP firmware is detected, without checking whether that GPU is the one driving your displays. On a laptop where the iGPU renders the session, every VA-API client is pointed at the wrong driver.

The override, reported working by a commenter on #10496 with an AMD iGPU, goes in ~/.config/hypr/hyprland.lua:

hl.env("LIBVA_DRIVER_NAME", "radeonsi")  -- use "iHD" on Intel iGPUs

Log out and back in, because environment changes only reach apps launched afterwards. If you want to confirm the diagnosis before editing anything, launch the browser once with the variable set and a throwaway profile.

If that did not work

• The picker never appears at all. Issue #10348 reports that on a fresh 4.0.2 install with Intel plus NVIDIA, the picker process starts and logs correctly but its window never reaches the compositor, and other Electron and GTK4 apps fail the same way. It is open with no fix as of 4.0.4. Check with hyprctl clients | grep -i picker while the prompt should be up.
• Sharing works but video decode is broken generally. That is the same LIBVA_DRIVER_NAME story, see NVIDIA on Omarchy.
• Nothing at all happens when the site asks. Restart the portal with systemctl --user restart xdg-desktop-portal-hyprland xdg-desktop-portal and try again before you dig further.

Evidence for Microsoft Teams specifically is thin. A search of the issue tracker on 2026-09-16 turned up no Teams screen sharing reports at all, so the honest answer is that Teams on the web goes through exactly the same portal path as Meet and nobody has filed anything against it.

What to watch for on newer versions

The next release is announced as Quattro RS 4.5. The share picker package pin from #11221 is the one to check first after any update: if the hyprland-preview-share-picker package moves past the upstream origin offset fix, the missing monitor workaround stops being necessary. The LIBVA_DRIVER_NAME detection in nvidia.lua is the other one. If it learns to ask which GPU drives the displays, remove your override rather than leaving a stale one behind.

Related

• NVIDIA on Omarchy
• Multi monitor setup
• Hyprland conf to Lua migration