Voice Typing on Wayland: Why Most Tools Break

Run this before you evaluate another dictation tool:

echo $XDG_SESSION_TYPE

If it prints wayland, and on a default Ubuntu, Fedora or KDE Plasma install in 2026 it will, then a large share of the Linux voice typing tools you are about to compare either do not run for you at all or need manual setup before they can put a single character on screen. Not because they are bad. Because Wayland deliberately removed the mechanism they were built on.

The escape hatch is closing too. Fedora 43 removed the GNOME X11 packages, Ubuntu 25.10 shipped its GNOME edition Wayland-only, and GNOME 50 dropped the X11 session entirely in March 2026. "Just log into X11 instead" is no longer advice you can give a new user.

This page explains what that mechanism was, why its removal breaks the tools you have tried, and how to tell in five minutes whether a given tool will work on your desktop.

What X11 Allowed, and Wayland Does Not

On X11, any client connected to the display server could do two things that dictation absolutely depends on:

1. Synthesise input into any window. The XTEST extension let a program generate key and pointer events that other applications received as though they came from real hardware. This is what xdotool does, and it is how essentially every X11-era dictation, macro and automation tool inserts text.
2. Grab keys globally. A client could ask the server to notify it whenever a key combination was pressed anywhere, which is how a push-to-talk hotkey works.

Both were possible because X11 has no isolation between clients. Any client could also read your keystrokes as you typed them into another window, which is the same capability viewed from the attacker's side.

Wayland's design removed it. A Wayland client cannot see or inject input into another client, and cannot claim a global shortcut on its own. That is the security model working as intended, and it is not going to be reversed.

So a dictation tool on Wayland needs different answers to two questions: how do I hear the hotkey, and how do I put text into an application I am not allowed to touch?

Why Tools Fail, and Why They Fail Differently

Two tools can both claim Wayland support and behave completely differently on your machine, because the thing they depend on is not the same thing.

The virtual keyboard protocol, and who implements it

virtual-keyboard-unstable-v1 is a Wayland protocol that lets a trusted client act as a keyboard. wtype uses it, and on compositors that implement it, it works well.

The catch is who implements it. GNOME's Mutter does not, and there is an open request in the Mutter tracker asking for it. On GNOME Wayland, which is the default session on Ubuntu and Fedora Workstation, wtype fails with:

Compositor does not support the virtual keyboard protocol

Sway, Hyprland and other wlroots-based compositors do implement it. So a tool that depends on wtype works on a tiling setup and fails on the two most common desktop installs in the world. If you are on Ubuntu or Fedora and a tool's setup instructions tell you to install wtype, that is the single most useful thing to notice before you spend an evening on it.

Everything else is a trade

The alternatives do not depend on the compositor, and they pay for that somewhere else: extra setup steps, device permissions that need a reboot, or a dependency you have to install yourself. That is the real reason Linux dictation tools vary so much in how much work they ask of you before the first sentence lands. The question worth asking of any tool is not which technique it uses, but how much of that cost it absorbs on your behalf.

The Problem Nobody Mentions: You Cannot Tell What Is Focused

On X11, asking which window has focus is one command. On Wayland there is no general way for an application to ask, by design.

This matters more than it sounds, because the right way to insert text is not the same everywhere. Ctrl + V is wrong in most terminals, where it is a control character. Konsole and Yakuake want Shift + Insert. The integrated terminals in Electron editors like VS Code and Cursor often read Ctrl + V as an image paste. A tool that cannot tell what it is typing into cannot reliably pick the right one, and the symptom is a stray ^V in your shell instead of your sentence.

Global Hotkeys Are a Separate Problem

Even with insertion solved, the push-to-talk key is its own question, because a Wayland client cannot claim a global shortcut on its own.

This is why some Linux dictation tools ask you to configure the hotkey yourself in GNOME Settings or your Hyprland config, rather than offering it in their own preferences. Handy's documentation says it plainly: "On Wayland, system-level shortcuts must be configured through your desktop environment or window manager. Use the CLI flags as the command for your custom shortcut."

That works. It also means the hotkey is not portable between your machines, does not show up in the app's own settings, and has to be redone on every desktop you use.

Where the Popular Tools Land

Checked against what each project publishes, in July 2026.

Tool	Wayland position
Talon	The download button says "Download for Linux (X11)". Wayland is not mentioned on the download page
Handy	README states "Limited support for Wayland display server". Requires wtype (preferred) or dotool; dotool requires adding your user to the input group; global shortcuts must be configured in your desktop environment; the recording overlay is disabled by default on Linux because "certain compositors treat it as the active window"
Wispr Flow, Superwhisper, Aqua Voice, Dragon and most commercial tools	No Linux build at all, so the display server question never arises. See 15 tools checked against their own platform support
Claude Code /voice	Works on Wayland, for an instructive reason. See below
Vibe Typer	Runs on Wayland and X11, with a guided setup on first launch

Handy's list is not a criticism of Handy, which is a good open-source project being honest in its README. It is an accurate picture of what building for Wayland actually costs, and every item on it is a step between you and dictating a sentence.

Why Claude Code's /voice Dodges All of This

Worth understanding, because it looks like a counterexample and is actually the clearest illustration of the rule.

Claude Code's /voice works fine on a Wayland session. It never touches the display server. It records audio inside its own process using a native module, falls back to arecord or SoX, and writes the transcript into its own prompt buffer. No input injection into another application. No global key grab. No compositor involvement at all.

Which is exactly why it cannot help you anywhere else. The reason it sidesteps every Wayland problem is that it never leaves its own window. The moment you want the same key to work in your browser, your editor, Slack or a second terminal, you are back to needing input injection, and back to everything above. See where /voice stops working for the rest of its limits.

What Vibe Typer Does

Vibe Typer ships as a single portable AppImage for modern 64-bit distributions, and runs on both Wayland and X11, including GNOME on Ubuntu and Fedora where wtype-based tools do not.

On a Wayland session it runs a guided setup on first launch rather than handing you a README: it detects your distribution, tells you what it needs, sets it up once with your approval, and asks for a restart. After that the push-to-talk key lives in Vibe Typer's own settings rather than your desktop's shortcut editor, and it moves with your account to your other machines.

Text insertion picks the right method per application, so terminals, Electron editors and ordinary text fields each get what they actually accept. If something on your setup behaves oddly, every one of those choices is overridable per application in text insertion and paste preferences.

Free for 2,000 words and 20 AI operations a month, no card. Pro is $10/month, or $8/month billed annually. Download Vibe Typer.

Notes by Compositor

GNOME / Mutter. The default on Ubuntu and Fedora Workstation, and the strictest of the major desktops. No virtual keyboard protocol, so wtype-based tools do not work here. If a tool works on GNOME Wayland it will generally work anywhere.

KDE Plasma / KWin. Generally the most cooperative of the big desktops. Shift + Insert is the reliable paste in Konsole and Yakuake. If a transparent recording indicator causes whole-screen blur or a tinted overlay, that is KWin's Blur desktop effect: see fixing blur when recording.

Sway, Hyprland, Niri. Implement the virtual keyboard protocol, so more tools work, but they are also the desktops most likely to apply unexpected rules to small transparent windows. The same blur guide covers Hyprland and Niri.

COSMIC. Newer, and paste behaviour differs enough to be worth its own page: see Pop!_OS COSMIC paste behaviour.

How to Test Any Tool in Five Minutes

1. Confirm you are on Wayland: echo $XDG_SESSION_TYPE.
2. Dictate into a plain text editor. If this fails, the tool cannot inject input on your compositor and nothing else matters.
3. Dictate into your terminal. This is where paste shortcuts go wrong, and where most tools first misbehave.
4. Dictate into a browser text field and into an Electron app such as VS Code, Slack or Discord. Electron apps are their own category.
5. Press the hotkey while a different application has focus. If nothing happens, the tool never got a global shortcut and you are about to configure one by hand.
6. Lock and unlock the session, then try again. Some setups lose their input device access.

If a tool passes all six on your desktop, it will hold up in daily use. Most X11-era tools fail at step 2 or 5.

Related Reading

• Running agents on a remote machine adds a second, unrelated problem: voice dictation over SSH and in dev containers.
• The platform support each vendor actually publishes: best AI voice typing apps for Linux.
• Coming from a tool with no Linux build at all: Wispr Flow Linux alternative.

FAQ

Why does my dictation tool not work on Wayland?

Almost certainly because it relies on X11's XTEST extension to synthesise keystrokes into other applications, which Wayland does not permit. Tools built for X11 either fail outright on a Wayland session or run only through Xwayland, where they can reach X11 applications but not native Wayland ones.

Does Talon work on Wayland?

Talon's download page offers "Download for Linux (X11)" and does not mention Wayland. If you are on a Wayland session, check its current documentation before assuming it will work.

Why does wtype say the compositor does not support the virtual keyboard protocol?

Because your compositor does not implement virtual-keyboard-unstable-v1. GNOME's Mutter is the common case, and it is the default on Ubuntu and Fedora Workstation. Tools that depend on wtype cannot type on those desktops.

Do I have to configure my hotkey in GNOME Settings?

With some tools, yes, because a Wayland client cannot grab a global shortcut by itself. Vibe Typer handles this during its guided setup so the hotkey lives in its own settings instead.

Does Vibe Typer work on Wayland?

Yes, on Wayland and X11, including GNOME on Ubuntu and Fedora. It ships an AppImage for modern 64-bit distributions and runs a guided setup on first launch, then asks for a restart.

Why does the text paste into my terminal incorrectly?

Ctrl + V is not a paste in most terminals. Vibe Typer sends Ctrl + Shift + V in known terminals and Shift + Insert for Konsole, Yakuake and the integrated terminals in VS Code and Cursor. You can set a different mode per application in paste preferences.

Should I just switch back to X11?

On some desktops you no longer can. Fedora 43 removed the GNOME X11 packages, Ubuntu 25.10's GNOME edition is Wayland-only, and GNOME 50 dropped the X11 session in March 2026. KDE Plasma still offers one, but the direction is settled. It is worth choosing a dictation tool that works on the session your distribution ships rather than one that requires you to keep an old session alive.