Suite / SnipSnap / Screenshots on Wayland
Screenshots on GNOME Wayland without a permission prompt
Wayland took the screen away from applications on purpose. That is the right decision, and it is why your screenshot tool got worse.
If you moved to Wayland and found that the tool you had used for years now asks permission before every capture, or can no longer drag a region across two monitors, nothing is broken. This page explains what actually changed, what the sanctioned fix costs, and the one place the problem can be solved instead of worked around.
What changed under Wayland
Under X11 any client could read the whole screen, including every other window. Screenshot tools relied on that, and so could a keylogger — the same privilege, with no way for the display server to tell them apart. Wayland closes it: a client sees its own surfaces and nothing else. There is no API for "give me the framebuffer", by design.
So a screenshot tool needs something outside itself to hand it pixels. On a modern desktop that something is xdg-desktop-portal: the application asks the portal, the portal asks the compositor, and the user is shown a dialog confirming the capture. It works, it is the right default for sandboxed applications, and it is a genuine security boundary — the point is that the user, not the program, decides.
What the portal path costs
A dialog before every capture
The prompt is the feature, not a bug — but a tool you reach for twenty times a day turns into forty interactions. Some compositors can remember the grant; GNOME's screenshot portal deliberately confirms each time.
One monitor at a time
The portal hands back a screen, and interactive selection happens inside the portal's own UI. A region that starts on one display and ends on another is not something the calling application gets to express.
Your own overlay is a window
A tool that draws its own dimmed selection layer is drawing a normal Wayland surface. It cannot cover what it does not own, cannot position itself across outputs, and under mixed scaling its rectangle and the real pixels disagree.
The other place to solve it
The compositor already has every pixel, knows where each monitor is, and knows each one's scale and rotation. On GNOME it is also extensible. So rather than asking the compositor for a screenshot through a broker, the selection itself can be drawn inside the compositor by a GNOME Shell extension: the dim layer and the rubber-band rectangle are Shell UI, and what comes back is exactly the region you dragged.
That is what SnipSnap does. One drag can begin on one monitor and end on another, with mixed scales and rotations, because at no point is a client trying to paint across outputs it does not own. There is no portal dialog, because there is no cross-application capture to authorise — the code drawing the selection is part of your desktop shell, installed by you.
The honest framing: this is not a way around Wayland's security model. It is a different trust decision. A Shell extension runs with the compositor's privileges, which is precisely why you should read one before installing it, and why the capture path is a package you install deliberately rather than something any application can reach.
What that buys, concretely
| Portal path | Compositor path | |
|---|---|---|
| Permission dialog | Every capture | None — the selection is Shell UI |
| Region across two monitors | Not expressible | One drag, mixed scales and rotations |
| Where the overlay is drawn | The portal's UI, or your own surface | Inside the compositor, over everything |
| Works on X11 | Yes | No — but the portal path is still there for it |
| Works on non-GNOME Wayland | Yes | No — the extension is GNOME Shell 50/51 |
Where this does not apply
You are on X11
Nothing described here is a problem for you. Any tool still works the old way, SnipSnap included — snipsnap gui, the tray icon and the D-Bus interface take the ordinary path on every desktop.
You are on Wayland but not GNOME
KDE, Sway and the rest each have their own answer; a GNOME Shell extension is not portable to them. The portal path is what you use, with a prompt and one monitor at a time.
You want a sandboxed package
A Flatpak or a Snap cannot install a Shell extension, which is the whole mechanism. That is why SnipSnap ships as a distribution package and not as either.
If you want to try it
SnipSnap is a downstream fork of Flameshot with the capture path moved into the compositor; the editor, CLI, tray icon and configuration file are Flameshot's, so the tool you already know is the tool you get. Installing it replaces the Flameshot package and copies your settings across without deleting the originals, and the flameshot command stays as a compatibility symlink.
Two details worth knowing before you build from source: the GNOME Shell bridge needs Shell 50 or 51, and you must configure with -DENABLE_GNOME_SHELL_BRIDGE=ON or you get a build without the compositor capture path — which is the reason the program exists. After installing, snipsnap-shell-bridge activate takes over the Print key, and only once the bridge is proven active.
- SnipSnap — what it does, install, where your data lives
- The GNOME Shell bridge — the socket protocol, and how the extension and the daemon meet
- Source on GitHub — read the extension before you install it