[BUG] Fedora ydotool client and daemon use different socket paths, breaking clipboard paste

Before You Submit

I searched existing issues before filing. #1831 and #1549 describe related Wayland/ydotool paste failures, but this has a different confirmed root cause: on Fedora 44, the packaged ydotool client and daemon use different default socket paths.

Bug Description

On KDE Plasma Wayland, Handy 0.9.6 successfully transcribes audio and writes the correct text to its history, but every clipboard paste method (Ctrl+V and Shift+Insert) fails with the generic notification:

Failed to paste text
Text could not be pasted into the active application.

Handy's log shows that it selects ydotool for the key combination, but ydotool exits unsuccessfully:

[INFO] Using paste method: CtrlV, delay before: 60ms, delay after: 60ms
[INFO] Using wl-copy for clipboard write on Wayland
[INFO] Using ydotool for key combo
[WARN] Could not recognize ydotool key --help output (exit status Some(2)); using raw-keycode syntax
[ERROR] Failed to paste transcription: ydotool failed:

Confirmed root cause

The Fedora 44 ydotool package installs a system service whose daemon starts without an explicit socket path:

ExecStart=/usr/bin/ydotoold

In this environment, ydotoold creates:

/tmp/.ydotool_socket

However, the ydotool 1.0.4 client defaults to:

/run/user/1000/.ydotool_socket

The paths do not match. This can be reproduced without Handy:

$ env -u YDOTOOL_SOCKET /usr/bin/ydotool key 0
failed to connect socket `/run/user/1000/.ydotool_socket': No such file or directory
Please check if ydotoold is running.

The daemon's /tmp socket also defaults to mode 0600 and initially belongs to the service user, so it must be made accessible to the desktop user.

Confirmed workaround

Configure the daemon socket ownership:

# /etc/systemd/system/ydotool.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/bin/ydotoold --socket-own=1000:1000

Then launch Handy with the daemon's actual socket path:

YDOTOOL_SOCKET=/tmp/.ydotool_socket

After restarting both services, this succeeds:

$ YDOTOOL_SOCKET=/tmp/.ydotool_socket /usr/bin/ydotool key 0
$ echo $?
0

Handy's Clipboard (Ctrl+V) paste method then works correctly, including Portuguese accented characters. Before this workaround, Direct mode through kwtype was the only insertion method that worked, but it could reorder accented characters under the US International layout.

Suggested fix

When invoking ydotool on Linux, Handy could detect the available socket and pass YDOTOOL_SOCKET to the child process. A possible lookup order is:

1. Existing YDOTOOL_SOCKET environment variable.
2. $XDG_RUNTIME_DIR/.ydotool_socket if it exists and is accessible.
3. /tmp/.ydotool_socket if it exists and is accessible.

If no usable socket exists, the UI/log should report the paths checked and the ownership/permission problem instead of returning an empty ydotool failed: message. Documentation could also mention that a system-wide ydotoold socket must be accessible to the desktop user.

System Information

App Version: 0.9.6 AppImage

Operating System: Aurora 44.20260908.1 (Fedora Kinoite 44 based), KDE Plasma 6.7.4, Wayland

Kernel: Linux 7.1.8-200.fc44.x86_64

CPU: AMD Ryzen 5 5600

GPU: NVIDIA GeForce RTX 3060 Ti, proprietary NVIDIA driver

ydotool: 1.0.4-8.fc44.x86_64

Desktop keyboard layout: US International (us, alt-intl)

Logs

Relevant Handy log excerpt:

[INFO] Using paste method: CtrlV, delay before: 60ms, delay after: 60ms
[INFO] Using wl-copy for clipboard write on Wayland
[INFO] Using ydotool for key combo
[WARN] Could not recognize ydotool key --help output (exit status Some(2)); using raw-keycode syntax
[ERROR] Failed to paste transcription: ydotool failed:

The same failure occurs with ShiftInsert. Transcription and clipboard writing succeed; only the simulated paste key combination fails.