1. Why xdotool stops at the Wayland boundary
xdotool simulates keys with X11’s XTEST extension and other Xlib calls, so it needs an X server. A Wayland session runs X11 programs inside XWayland; xdotool can still type into those windows, but native Wayland apps never see its events. Its README is blunt: under Wayland, typing, window searching and many other functions do not work, “and it is unclear if they could ever work.”
Under Wayland the compositor owns input. A program can inject keystrokes only through a protocol the compositor chooses to expose, or by creating a virtual device in the kernel, below the compositor. The virtual-keyboard protocol itself tells compositors to refuse untrusted clients when a keyboard could perform arbitrary actions, which is one reason support differs from desktop to desktop.
- Confirm the session: echo $XDG_SESSION_TYPE prints wayland.
- Identify the compositor: GNOME runs Mutter, KDE Plasma runs KWin, Cinnamon runs Muffin.
- Pick the helper that compositor allows, using the sections below.
2. wtype and the virtual-keyboard protocol
wtype describes itself as “xdotool type for wayland”. It creates a virtual keyboard through the zwp_virtual_keyboard_manager_v1 protocol, so it works only where the compositor implements that interface. Wayland Explorer’s support table lists Sway 1.11, Hyprland 0.52.1, labwc, niri, river, Wayfire, COSMIC, Cage, phoc and Mir as supporting it, and Mutter (GNOME), KWin (KDE), Muffin (Cinnamon), Weston and Gamescope as not supporting it.
Its usage mirrors xdotool’s typing: wtype 'text' types a string, -d sets a delay between keystrokes in milliseconds, and echo text | wtype - reads from standard input. When wtype exits, the compositor destroys its virtual keyboard and any held modifiers are released. Current Debian and Ubuntu releases package it as wtype 0.4.
3. kwtype for KDE Plasma
KWin does not offer the virtual-keyboard protocol to ordinary apps, so wtype fails on Plasma. KWtype fills the gap with KDE’s own fake-input protocol, a privileged interface implemented only by KWin. You run kwtype followed by the text to type.
It is a small MIT-licensed C++ project you build yourself with meson against Qt 6, KWayland and xkbcommon: meson setup --buildtype=release build, then meson install -C build. Ubuntu’s archive has no kwtype package as of October 2026. If building is not an option, the uinput tools in the next section also work on Plasma.
4. dotool and ydotool: typing below the compositor
dotool and ydotool skip Wayland protocols entirely. They create a virtual input device with the kernel’s uinput module, so GNOME, KDE, Cinnamon, wlroots compositors and even a text console see what looks like a real keyboard. That is why they are the usual answer on GNOME, which offers apps no typing protocol at all.
The cost is permission. dotool needs write access to /dev/uinput, which its udev rule grants to the input group; ydotool’s daemon, ydotoold, needs the same device and, its README notes, usually root. Anything that can write to /dev/uinput can type into any window, so grant it deliberately. Keyboard layouts are the other catch: dotool reads DOTOOL_XKB_LAYOUT and DOTOOL_XKB_VARIANT to match your layout and handles dead keys only heuristically, while ydotool’s README says it does not recognize custom layouts.
- Install dotool from Alpine, Arch (AUR), Nix or Void, or build it from source.
- Join the input group: sudo usermod -a -G input $USER, then reboot.
- Test it: echo type hello | dotool
- Non-US layout: echo type azerty | DOTOOL_XKB_LAYOUT=fr dotool
5. The input-method route: IBus engines and Myna
A third approach avoids fake keystrokes. An input method commits text straight into the focused field, the way Chinese or Japanese input does. IBus Speech To Text is an IBus engine that runs VOSK locally; its README says it works on Wayland and should reach most apps because GTK and Qt support IBus. It was last updated in November 2022, so expect to build it yourself.
Canonical’s Myna, targeted at Ubuntu 26.10, takes the same path: OMG! Ubuntu’s hands-on describes it passing transcripts to apps through IBus, with a Wayland-native input method planned for a later release. Input methods need no /dev/uinput access, which is their main advantage over the tools above.
6. Bind the dictation hotkey through your desktop
On X11 an app can grab a key for itself; on Wayland that belongs to the desktop. The XDG Desktop Portal’s GlobalShortcuts interface lets an app register shortcuts that fire regardless of which window has focus, with the desktop presenting a dialog to confirm the binding. Speech Note’s README notes that only recent GNOME and KDE Plasma releases support it, and Ubuntu’s 26.04 release notes list app-defined system-wide shortcuts as a GNOME 48 addition.
When an app does not use the portal, bind its command line instead. IraVoice’s global shortcut may not reach it on Wayland, so bind iravoice --toggle-transcription (with the AppImage, its full path followed by --toggle-transcription), which starts or stops a dictation in the running app. IraVoice then types with whichever helper fits, choosing among wtype, kwtype, dotool and ydotool on Wayland and xdotool on X11; you may need to install one first, and Wayland support is limited in the Linux beta.
- GNOME: Settings → Keyboard → View and Customize Shortcuts → Custom Shortcuts → Add Shortcut.
- KDE Plasma 6: System Settings → Keyboard → Shortcuts → Add New → Command or Script.
- Sway: bindsym $mod+o exec iravoice --toggle-transcription
- Hyprland: bind = $mainMod, O, exec, iravoice --toggle-transcription