Text input does not work in terminal emulators (GNOME Terminal, xterm) - only ^M visible

[seeli-teaching]

Text input does not work in terminal emulators (GNOME Terminal, xterm) - only ^M visible

Description

QSpeak transcription works correctly in GUI applications (e.g., VS Code, text editors), but fails to input any text in terminal emulators. After speaking and having QSpeak process the transcription, no text appears in the terminal. However, when pressing Enter afterward, the terminal displays ^M (carriage return character), indicating that some input events are being received but not the actual text content.

Environment

• OS: Pop!_OS (Ubuntu-based)
• Display Server: X11 (echo $XDG_SESSION_TYPE returns x11)
• Terminal: GNOME Terminal (gnome-terminal-)
• TERM variable: xterm-256color
• QSpeak Hotkey: F6 (simple key, no modifiers)
• xdotool installed: Yes (/usr/bin/xdotool)

Steps to Reproduce

1. Open GNOME Terminal
2. Ensure terminal window has focus
3. Press F6 to start QSpeak recording
4. Speak some text (e.g., "hello world")
5. Press F6 to stop recording and trigger transcription
6. Observe that no text appears in the terminal
7. Press Enter
8. Observe ^M character appears

Expected Behavior

Transcribed text should appear in the terminal at the cursor position, the same way it works in GUI applications like VS Code.

Actual Behavior

• No visible text is typed into the terminal
• Only ^M (carriage return, \r) appears after pressing Enter
• This suggests keypress events may be partially reaching the terminal but the actual character input is being rejected or lost

Additional Testing Performed

xdotool works manually

Running xdotool type --delay 50 "hello from xdotool" in a separate window successfully types text into GNOME Terminal when it has focus. This confirms:

• xdotool itself works with the terminal
• The terminal accepts synthetic keyboard input via XTEST
• The issue is specific to how QSpeak sends input

GUI applications work fine

QSpeak correctly inputs transcribed text into:

• Visual Studio Code
• Other GUI text editors

Possible Causes

Based on research, this could be related to:

1. enigo library behavior: QSpeak likely uses the enigo Rust crate for input simulation, which uses libxdo (xdotool's library) on Linux. There may be differences in how enigo sends events compared to direct xdotool usage.

2. Missing --clearmodifiers equivalent: The enigo library may not be clearing active modifiers before typing, which can cause issues (see [enigo issue #83](Clear modifiers before typing enigo-rs/enigo#83)).

3. Window targeting: If enigo is sending events to a specific window ID rather than using XTEST to type to the active window, terminals may reject these events due to the send_event flag (see [xdotool SENDEVENT NOTES](https://manpages.ubuntu.com/manpages/trusty/man1/xdotool.1.html#sendevent%20notes)).

4. Line ending handling: The ^M character suggests carriage returns (\r) are being sent but not translated properly by the terminal.

Suggested Solutions

1. Add a clipboard-paste mode: Instead of simulating keystrokes, copy transcribed text to clipboard and simulate Ctrl+Shift+V for terminal windows. This is more reliable for terminals.

2. Use XTEST API: Ensure enigo is using the XTEST extension (typing to active window) rather than XSendEvent (sending to specific window ID).

3. Clear modifiers: Call xdo_clear_active_modifiers before typing to prevent modifier key interference.

4. Detect terminal windows: Optionally detect when the focused window is a terminal emulator and use an alternative input method.

Related Issues / References

• [enigo: Clear modifiers before typing (#83)](Clear modifiers before typing enigo-rs/enigo#83)
• [enigo: Support linux via x11 without xdotools (#112)](Support linux via x11 without xdotools enigo-rs/enigo#112)
• [xdotool SENDEVENT NOTES](https://manpages.ubuntu.com/manpages/trusty/man1/xdotool.1.html#sendevent%20notes)
• [Similar app "Handy" notes about enigo limitations](https://github.com/cjpais/Handy) - falls back to xdotool/ydotool directly due to enigo compatibility issues

Workaround Requests

Would it be possible to add an option for "clipboard paste mode" that:

1. Copies transcribed text to clipboard
2. Simulates Ctrl+Shift+V (standard terminal paste shortcut)

This would provide a reliable workaround for terminal users.

---

Thank you for this great tool! Happy to provide any additional debugging information needed.

[bnewsond]

Given xdotool type works in GNOME Terminal but QSpeak doesn’t, this looks like an input-injection backend mismatch (terminals often ignore send_event / non-XTEST style typing).

Could add an optional “terminal mode” that copies the transcription to the clipboard and then sends Ctrl+Shift+V to paste. You can have that in terminals and avoids per-key injection issues.