wearewaylandnow.com

What is We are Wayland now!?

We are Wayland now! is a reference page that tracks whether common desktop Linux tasks and applications work under Wayland, the display protocol that has largely replaced X11. Its headline answer is deliberately qualified: "Yes, we are Wayland now! (mostly)." The site organizes the answer by task — application launcher, clipboard manager, color management and HDR, dock, file manager, game launcher, hotkeys, login manager, and so on — and lists the tools that fill each role.

It is not a tutorial, a distribution, or a download. Think of it as a status board: useful when you are moving to a Wayland session and want to know whether the thing you depend on has a native replacement, a workaround, or no answer yet.

H3 How to use it in practice

Suppose you are switching a KDE Plasma or GNOME desktop to Wayland and you rely on a clipboard history tool. You can look up the clipboard manager entry and see several candidates rather than guessing. The same applies to launchers, notification daemons, screen-sharing helpers, and gaming utilities.

The value is in the grouping. Instead of searching one project at a time, you get a checklist of categories that a working desktop actually needs — input remapping, display configuration, emoji pickers, document viewers, and more.

H3 What to keep in mind

• "Mostly" is doing real work in the title. Some entries are marked experimental, partial, alpha, or unmaintained, and those labels matter more than the length of the list.
• A listed tool is not automatically a drop-in replacement. Check whether it fits your compositor (GNOME, KDE Plasma, Hyprland, Sway/wlroots) and your distribution's packaging.
• The page is a starting point for research, not a guarantee. Confirm current support with the project itself before rebuilding your workflow around it.

For broader context on the protocol and its ecosystem, see Wayland and, for compositor-specific guidance, ArchWiki. Your next step: pick the one or two tools you cannot live without, look them up on this page, then verify each against its own project page before switching sessions.

How do I find out if my favorite Linux app works on Wayland?

Use We are Wayland now! as a first-pass checklist. Its page is organized by app category — launchers, clipboards, email clients, emulators, file managers and more — and each entry names a Wayland-friendly option. So the fastest method is: identify what your app does, find that category, and see whether your app or a close replacement is listed.

A practical workflow

1. Name the job, not the app. “Clipboard manager” or “hotkey daemon” is easier to match than a specific product name.
2. Check the category list. If your app appears, note whether the page marks it as partial, experimental or alpha — those labels matter more than the name being present.
3. If it is absent, test it under Wayland anyway. Many apps run fine through XWayland even when they are not listed as native.
4. Look for the failure mode. Typical Wayland-specific breakages are global hotkeys, screen capture, clipboard access, window positioning and autotype — features that need desktop portals or compositor support.
5. Check your compositor, not just “Wayland.” GNOME, KDE Plasma, Hyprland and wlroots-based compositors implement protocols differently, so an app can work on one and not another.

Quick comparison

Concrete example

Suppose you rely on a clipboard manager. The page lists several, including cliphist, wl-clipboard and CopyQ. If your current tool is not there, that is a signal to test whether it can read the Wayland clipboard at all — a common point of failure — rather than assuming the whole app is broken.

For a second opinion, cross-check with your distribution’s wiki, such as ArchWiki, and with the compositor’s own documentation. Your desktop environment’s release notes are also useful, because portal and protocol support changes between versions.

The decision rule: if your app is listed and your compositor is supported, use it. If it is listed as partial, test the exact feature you depend on. If it is absent, try XWayland and keep a native alternative in mind as a fallback.

What are the best Wayland alternatives to X11 tools like Rofi or Dunst?

Rofi and Dunst are X11-native, so they don't run natively on Wayland compositors. The site's own list of Wayland-ready replacements is the most direct answer for what people actually use.

Application launchers (Rofi alternatives)

The page lists: Albert, Anyrun, bemenu, dmenu-wayland, Fuzzel, gmenu, nwg-launchers, Onagre, Rofi, Tofi, Ulauncher, walker, wmenu, Wofi, yofi.

• Fuzzel and Wofi are the common drop-in replacements. Fuzzel is lightweight and fast; Wofi is more configurable and closer to Rofi's scriptable feel.
• bemenu and dmenu-wayland suit people who want a minimal, dmenu-style pipeline.
• walker and Anyrun target users who want a more modern, extensible launcher.
• Rofi itself appears in the list, but note that Rofi's Wayland support has historically lagged behind X11; check the current state before relying on it.

Notification daemons (Dunst alternatives)

The page lists: Dunst, Fnott, mako, SwayNotificationCenter.

• mako is the minimal, compositor-agnostic choice, popular on Sway and wlroots-based setups.
• SwayNotificationCenter adds a control center with history and a panel, closer to a full notification hub.
• Dunst itself is listed—it can work under some Wayland setups, but it's not a native Wayland client, so behavior varies.
• Fnott is a lightweight option worth considering if you want something small.

How to choose

A practical next step: check which compositor you run (Sway, Hyprland, GNOME, KDE Plasma) and pick tools known to integrate with it. For example, SwayNotificationCenter pairs naturally with Sway, while GNOME and KDE users often get launchers and notifications from the desktop environment itself rather than a third-party replacement.

The site We are Wayland now! is a useful reference for checking status and alternatives across categories, not just launchers and notifications.

Is my desktop environment (GNOME, KDE, Sway, etc.) fully supported on Wayland?

Support varies by desktop environment. The page’s own summary is “Yes, we are Wayland now! (mostly)” — so treat “fully supported” as a per-feature question, not a yes/no per DE.

What the page lists as supported

How to read that

• GNOME and KDE Plasma appear throughout the list — HDR, DisplayLink, hotkeys, output tools — which suggests the broadest coverage.
• Sway/wlroots appears for DisplayLink, and Sway has its own notification daemon (SwayNotificationCenter) and dock options, but the page does not list it as having stable HDR support.
• Compositors like Hyprland show up for HDR and global hotkeys via a custom implementation, not the portal path.
• “Experimental,” “partial” and “Alpha” labels are the page’s own, so Cinnamon, LXQt, MATE and COSMIC carry caveats.

A practical next step

Pick the two or three things you actually depend on — say, DisplayLink for a dock, global push-to-talk, HDR, or KeePass autotype — and check whether your DE is named next to each. A DE can be fine for daily use yet miss one feature you need.

For example, if you use a DisplayLink dock and global push-to-talk, GNOME or KDE Plasma look safest from this list; if you run Sway, verify your specific dock and hotkey setup before switching.

Related reading: ArchWiki maintains detailed per-feature notes, and Wayland documents the protocol side.

How can I fix common Wayland issues like Discord push-to-talk or global hotkeys?

Discord push-to-talk and global hotkeys are the two Wayland problems people hit most often, because both depend on an app receiving keyboard input while it is not focused. Wayland deliberately restricts that for security, so the fix is usually a portal or a compositor-specific setting rather than a flag inside Discord.

Discord push-to-talk

On X11, Discord could grab a key globally. On Wayland it generally cannot, so you have three practical routes:

• Use the global shortcuts portal. If your compositor implements it, Discord can request a shortcut through the desktop portal and push-to-talk starts working without extra tools. GNOME has this implemented; Hyprland supports it through a custom implementation. KDE Plasma and wlroots-based compositors vary, so check your compositor's current state before assuming it works.
• Use a wrapper client. Vesktop and WebCord are listed as Discord clients/workarounds, and both are commonly used because they handle input and screen sharing better under Wayland than the official Electron client. This is the least fiddly option if you just want voice chat to behave.
• Bind the key yourself. If the portal path fails, map a key in your compositor to a command that toggles Discord's mute/deafen state, or use a hotkey daemon. That is a workaround, not true push-to-talk, but it is reliable.

Whose observation is this? The site's own listing is the source for the portal and client names above. My practical read: try the wrapper client first, because it solves push-to-talk and screen sharing in one step, and only dig into portal configuration if you need the official client for a specific feature.

Global hotkeys

The general pattern is: compositor-native bindings first, a hotkey daemon second.

• Compositor bindings are the most reliable and lowest-latency option. If your compositor can bind a key to a shell command, use that before adding another daemon.
• swhkd is listed as a hotkey daemon for when you need bindings the compositor does not expose, or you want one config across compositors.
• Keyboard remappers (keyd, kanata, KMonad, keyd-style tools such as input-remapper and Interception Tools) operate at a lower level. They are the right choice when you want a key to behave differently system-wide, not just trigger a command.

Quick comparison

A concrete next step

Identify your compositor first, because the answer changes completely between GNOME, KDE Plasma, Hyprland and Sway/wlroots. Then check whether the global shortcuts portal is active; if it is, most of these problems disappear. If it is not, pick a wrapper client for Discord and native bindings for everything else, and treat a hotkey daemon as the fallback rather than the default.

For the full, current list of what works and what does not, see We are Wayland now!, which tracks these categories as support changes.

What is the current status of HDR and color management on Wayland?

HDR and color management on Wayland are supported in principle, but practical readiness depends on your compositor and your applications. The site's own summary is blunt about the state of play: a Wayland protocol exists, with stable support in KDE Plasma, Hyprland and Firefox. That combination is enough for many desktop users, but it is not a uniform, everything-works situation across the ecosystem.

What that means in practice

• The protocol layer is no longer the blocker; it exists.
• Compositor support is the deciding factor. KDE Plasma and Hyprland are named as stable, while other compositors may lag or require manual configuration.
• Application support is narrower than compositor support. Firefox is called out specifically; many other apps either ignore HDR metadata or need workarounds.

H3. A concrete scenario You have an HDR-capable monitor and want to watch HDR video in a browser while keeping your desktop color-accurate. On KDE Plasma or Hyprland, with Firefox, this is a realistic setup. On a compositor not listed as stable, expect to spend time on configuration, and expect some apps to render washed-out or over-bright output.

How to decide

A useful next step is to check your compositor's own documentation for HDR and color management before buying an HDR display for a Wayland desktop, and to test with the specific applications you rely on rather than assuming broad support. The We are Wayland now! page is a reasonable starting point for seeing which tools and environments are tracked as working.