Voice dictation on Wayland¶
Short answer: Wayland deliberately blocks one application from typing into another, which is why most Linux dictation tools silently stop working after a switch from X11. YazSes gets around it with ydotool, which injects at the kernel uinput layer instead of through the display server — so dictated text lands in GNOME, KDE Plasma, sway and Hyprland, terminals included.
sudo snap install yazses # or: pipx install yazses
yazses doctor # reports your session type and which backend was picked
yazses start # hold the hotkey, speak, release
Why does dictation break on Wayland?¶
Because X11 let any client synthesise input into any window, and Wayland closed that hole on purpose. It is a security fix, not a bug. Every tool built on xdotool inherited the assumption and breaks the moment the session becomes Wayland — usually with no error message, because the injection call succeeds and the keystrokes simply go nowhere.
Ubuntu has defaulted to Wayland since 22.04 and Fedora since 25, so this is now the default case on Linux, not the exception.
Check which session you are in:
Which injection backend works on which compositor?¶
YazSes probes the session at runtime and picks a backend rather than assuming one. yazses doctor prints the choice and whether it is functional.
| Backend | Mechanism | GNOME | KDE Plasma | sway / Hyprland | Types into terminals? |
|---|---|---|---|---|---|
ydotool (default on Wayland) | Kernel uinput virtual keyboard — below the compositor | ✅ | ✅ | ✅ | ✅ |
wtype | virtual-keyboard-v1 Wayland protocol | ❌ (GNOME does not implement the protocol) | ✅ | ✅ | ✅ |
clipboard | Copies text, sends paste | ✅ | ✅ | ✅ | ❌ (terminals use a different paste binding) |
xdotool | X11 XTEST | X11 only | X11 only | X11 only | ✅ |
The practical consequence: ydotool is the only backend that works on all four compositors including GNOME, which is why it is the default. wtype is cleaner but GNOME has declined to implement virtual-keyboard-v1, so it is not a general answer.
Pin a backend explicitly if the probe picks badly:
How do I set up ydotool?¶
ydotool needs a running daemon and access to /dev/uinput. yazses setup provisions both:
yazses setup # installs ydotool, enables ydotoold, fixes uinput permissions
yazses doctor # confirms the backend is functional
If you prefer to do it by hand, the daemon must be running and your user needs write access to /dev/uinput — typically via a udev rule and group membership, followed by a re-login so the new group takes effect.
Does the hotkey work on Wayland?¶
Yes. The hold-to-talk key is read from the kernel input layer (evdev), not from the compositor, so a global hotkey works on Wayland without a per-desktop shortcut extension. YazSes listens on all connected keyboards, so an external keyboard works alongside the laptop one.
This does mean your user needs to be in the input group:
What still does not work on Wayland?¶
Being straight about the limits, because they are real:
| Feature | Wayland | Why |
|---|---|---|
| Dictation into any app | ✅ | ydotool injects below the compositor |
| Global hold-to-talk hotkey | ✅ | Read from evdev, not the compositor |
| Voice commands / key sequences | ✅ | Same injection path |
| Meeting Mode, file transcription | ✅ | No injection involved |
| Glance-Type (look-to-pane targeting) | ❌ X11 only | Wayland gives no client the ability to focus another application's window |
Glance-Type stays dormant on Wayland rather than half-working. If gaze-directed window targeting matters to you today, that specific feature needs an X11 session.
Text still is not appearing — what now?¶
Work down this list; yazses doctor answers most of it for you.
- Confirm the session —
echo $XDG_SESSION_TYPEshould saywayland. - Confirm the backend —
yazses doctorreports which injector was selected and whether it passed its functional check. - Is
ydotooldrunning? —systemctl status ydotoold. Without the daemon,ydotoolfails silently. /dev/uinputpermissions — the daemon needs write access;yazses setupfixes this.- Nothing recorded at all? — that is a microphone problem, not a Wayland one. Run
yazses mic-level --set, which measures your room and writes a working voice-activity threshold. - Still stuck —
yazses verifyruns the whole chain (capture → silence gate → transcription → injection) and names the first broken link rather than cascading errors.
See troubleshooting for the full matrix.
How does this compare to other Wayland dictation tools?¶
| Tool | Wayland | Offline | Platforms | Notes |
|---|---|---|---|---|
| YazSes | ✅ ydotool | ✅ always | Linux, macOS, Windows | Also does file transcription and meeting capture in one install |
| Vocalinux | ✅ | ✅ | Linux only | Vulkan GPU acceleration; larger community |
| nerd-dictation | ⚠️ via ydotool/wtype | ✅ | Linux only | Single Python file, no background process — minimal by design |
| VOXD | ✅ | ✅ | Linux only | Wayland-focused |
| Hyprvoice | ✅ | mixed | Linux only | Hyprland-oriented; cloud and local models |
Where the others win: nerd-dictation is far smaller if you want a script rather than a daemon, and Vocalinux has GPU acceleration and many more users. YazSes's distinct claims are being cross-platform and covering dictation, file transcription and meeting capture from one install.
Full breakdown: comparison and alternatives.
Accuracy and speed on CPU¶
Wayland changes nothing about recognition quality — the same on-device model runs either way. Measured word error rate on LibriSpeech test-clean, int8 on a laptop CPU with no GPU:
| Model | WER | Decode (median) |
|---|---|---|
tiny.en | 4.82 % | 0.89 s |
base.en (default) | 4.07 % | 1.56 s |
small.en | 2.59 % | 5.05 s |
Method, hardware and reproduction commands: benchmarks.
Next steps¶
- Install on Linux — distribution-by-distribution
- Change the hotkey
- Troubleshooting
- Voice dictation on Linux — the X11 side of the story