Description

On Linux Wayland (COSMIC desktop / cosmic-comp), all enigo-based paste methods (ctrl_v, ctrl_shift_v, shift_insert) cause the TranscriptionManager to stall/deadlock on subsequent transcription attempts. The first transcription completes successfully, but the second TranscribeAction::start hangs indefinitely — no transcription output, no error, the app just stops responding to transcription requests.

paste_method: "none" and paste_method: "direct" (wtype) do not exhibit this issue.

Environment

• Handy version: 0.7.3
• OS: Pop!_OS 24.04 (Ubuntu-based)
• Desktop: COSMIC (smithay-based compositor)
• cosmic-comp: 0.1~1770304347~24.04~0e97ddb
• wayland-protocols: 1.45
• Kernel: 6.18.7-76061807-generic
• Trigger method: SIGUSR2 via COSMIC keyboard shortcut

Steps to Reproduce

1. Set paste_method to ctrl_shift_v (or ctrl_v / shift_insert)
2. Set clipboard_handling to copy_to_clipboard
3. Trigger a transcription — first one completes successfully
4. Trigger a second transcription — TranscribeAction::start hangs with no output

Log Evidence

With paste_method: CtrlShiftV — stalls on second attempt:

[17:43:15] TranscribeAction::start called for binding: transcribe
[17:43:15] TranscribeAction::start completed in 232ms
[17:43:16] Shutting down TranscriptionManager
[17:43:19] Transcription result: Testing, testing. One, two, three.
[17:43:19] Using paste method: CtrlShiftV, delay: 60ms
[17:43:21] Idle watcher thread shutting down gracefully
[17:43:21] Shutting down TranscriptionManager
[17:43:28] TranscribeAction::start called for binding: transcribe
           ← NOTHING AFTER THIS — stalled/deadlocked

With paste_method: Direct (wtype) — works consecutively:

[17:49:43] TranscribeAction::start called for binding: transcribe
[17:49:45] Transcription result: Testing.
[17:49:45] Using paste method: Direct, delay: 60ms
[17:49:54] TranscribeAction::start called for binding: transcribe  ← works fine
[17:49:57] Transcription result: Passing?
[17:50:00] TranscribeAction::start called for binding: transcribe  ← works fine again
[17:50:03] Transcription result: The quick brown fox jumps over the lazy dog.

With paste_method: None — works consecutively:

[19:10:51] TranscribeAction::start called for binding: transcribe
[19:10:55] Transcription result: Testing testing one two three.
[19:10:55] Using paste method: None, delay: 60ms
[19:11:01] TranscribeAction::start called for binding: transcribe  ← works fine
[19:11:04] Transcription result: Perhaps.
[19:11:20] TranscribeAction::start called for binding: transcribe  ← works fine again
[19:11:23] Transcription result: Testing, testing one two three.

Analysis

The common factor in the stalling paste methods is enigo — they all use enigo to simulate key events via an X11 connection (XWayland) on Wayland. The direct method uses wtype (an external process), and none skips pasting entirely — neither use enigo for the paste step, and neither exhibit the stall.

The stall pattern suggests enigo's X11 keyboard simulation on Wayland interferes with the TranscriptionManager's internal state, possibly through:

• Blocking or contending on a shared resource (mutex, condvar) during key simulation
• The X11 connection state interfering with the signal handler or event loop
• A timing interaction between enigo's key release events and the idle watcher thread

Additional Context: direct (wtype) is also broken

Separately, paste_method: "direct" (wtype v0.4-3) outputs raw keycodes instead of text characters on updated Wayland compositors. This is caused by a Smithay regression (Smithay#1926) where the compositor's virtual keyboard handler uses the seat's keymap instead of the virtual keyboard's custom keymap. A fix is in progress (Smithay PR #1903).

This affects cosmic-comp (pop-os/cosmic-comp#2081) and niri (niri#2314). wtype itself is unmaintained since 2022 (wtype#71).

This means no paste method currently works correctly on affected Wayland compositors — enigo-based methods stall the app, and wtype outputs garbage.

Workaround

Setting paste_method: "none" with clipboard_handling: "copy_to_clipboard" avoids all issues. Transcribed text is correctly copied to the Wayland clipboard via wl-copy, and the user can paste manually with Ctrl+Shift+V.

Suggested Fix Directions

• Investigate why enigo's X11 key simulation on Wayland causes TranscriptionManager stalls — possibly a threading/locking issue
• Consider adding ydotool or dotool (kernel uinput-based) as paste method alternatives that bypass both enigo and Wayland protocol issues
• Consider libei/eitype as a future-forward Wayland-native input emulation path (once compositor support matures)
• The wtype/direct paste issue will resolve upstream once Smithay PR #1903 is merged and compositors update