#2275

[BUG] KDE Plasma Wayland (CachyOS): Direct paste silently falls back to enigo/X11 and nothing reaches Wayland-native apps, but Handy logs success

OpenEasyDevvopened 17d ago

Bug Description

On CachyOS with KDE Plasma (Wayland), the default Direct paste method never delivers the transcription to Wayland-native apps (I tested with Kate), yet Handy logs Text pasted successfully. Recording, the global shortcut (Ctrl+Space) and transcription all work; only the final text insertion is lost, with no error or warning.

What I see in the log (paste method Direct, typing_tool = auto, none of wtype/kwtype/dotool/ydotool installed):

[handy_app_lib::clipboard][INFO] Using paste method: Direct, delay before: 60ms, delay after: 60ms
[handy_app_lib::clipboard][INFO] Falling back to enigo for direct text input
[enigo::platform::x11][WARN] fast text entry is not possible on X11
[enigo][DEBUG] fast text entry not available. Trying to enter individual letters now   (xtest_fake_input calls follow)
[handy_app_lib::actions][DEBUG] Text pasted successfully in 88.964226ms

The fallback is enigo's X11/XTEST backend. XTEST events only reach XWayland clients, so a Wayland-native window such as Kate receives nothing. Handy still reports success.

Other things I noticed while digging into this:

  • kwtype is the only tool in Handy's list that targets KDE Wayland, but it is not in the official Arch/CachyOS repos (only the AUR kwtype-git), so most KDE users fall into the silent enigo-X11 fallback. wtype needs a wlroots-style virtual-keyboard protocol that KWin doesn't provide (see #2006).
  • Korean (non-ASCII) text can't be typed key by key by the keycode-based tools (my expectation for wtype/ydotool; I did not test them), so for my language only a clipboard-based paste can work. I did not test the Clipboard (Ctrl+V) method, but it has to inject a key combo through the same tools, so I expect the same fallback problem.

Expected behavior

Either the transcription is inserted into the focused Wayland window, or Handy tells the user that insertion is not possible in this session (log level WARN/ERROR and ideally a UI hint), instead of reporting success.

Workaround that works

Paste method = External script with a script that puts the text on the clipboard and sends a real Ctrl+V through a /dev/uinput virtual keyboard (the user already has ACL access to /dev/uinput on this distro). Handy passes the text as $1:

#!/usr/bin/env bash
unset PYTHONHOME PYTHONPATH LD_LIBRARY_PATH LD_PRELOAD APPDIR APPIMAGE   # see note below
text="$1"; [ -n "$text" ] || exit 0
prev=""; had_prev=0
if wl-paste --list-types 2>/dev/null | grep -q '^text/plain'; then
  prev=$(wl-paste -n 2>/dev/null; echo x); prev=${prev%x}; had_prev=1
fi
printf '%s' "$text" | wl-copy || exit 1
sleep 0.05
/usr/bin/python3 - <<'PY' || exit 1
import time
from evdev import UInput, ecodes as e
ui = UInput({e.EV_KEY: [e.KEY_LEFTCTRL, e.KEY_V]}, name="handy-paste-keyboard")
time.sleep(0.5)
for code, val in ((e.KEY_LEFTCTRL, 1), (e.KEY_V, 1), (e.KEY_V, 0), (e.KEY_LEFTCTRL, 0)):
    ui.write(e.EV_KEY, code, val); ui.syn(); time.sleep(0.03)
time.sleep(0.15); ui.close()
PY
[ "$had_prev" = 1 ] && { sleep 0.4; printf '%s' "$prev" | wl-copy; }
exit 0

With this, Ctrl+Space → speak → Ctrl+Space inserts the Korean transcript into Kate; I verified the document content equals the entry in Handy's history, and the previous clipboard is restored.

Note for anyone copying it: the AppImage leaks its bundled PYTHONHOME/PYTHONPATH/LD_LIBRARY_PATH into the child process, which makes the system python3 die with No module named 'encodings' (script exit code 1 → Failed to paste transcription). Handy could scrub these variables before spawning the external script.

Suggestions

  1. On Wayland sessions, don't treat the enigo-X11 fallback as a successful paste; warn the user (or return an error) when the focused window can't be reached.
  2. Consider a built-in Wayland-capable path for KDE/GNOME that doesn't depend on AUR-only tools (e.g. the xdg-desktop-portal RemoteDesktop/libei input emulation, or /dev/uinput).
  3. Scrub AppImage-specific env vars (PYTHONHOME, PYTHONPATH, LD_LIBRARY_PATH, ...) for the External script method.
  4. Document the External script workaround for KDE Wayland.

Related: #2006 (typing tool dropdown on KDE/GNOME Wayland), #1555 (Wayland meta issue), #1729 (AppImage GDK_BACKEND=x11 rendering freeze on the same setup).

System Information

App Version: 0.9.8 (AppImage, run with GDK_BACKEND=wayland via the workaround from #1729; the enigo-X11 fallback above was observed in this configuration)

Operating System: CachyOS x86_64, KDE Plasma 6.7.5 (KWin Wayland session, XDG_SESSION_TYPE=wayland)

CPU: AMD Ryzen 7 5800X

GPU: NVIDIA GeForce RTX 3090

Logs

Relevant excerpt is inline above; transcription text is redacted by Handy's log.

Activity

1
cjpais17d ago

I think this is most likely a duplicate, or at the least known, it's largely a reason why we have multiple paste methods and the external script

Not 100% sure but I am not surprised by this, and it's likely not something easily fixable