fix: support X11 sessions, not just Wayland - #206
Merged
Conversation
Remove the pulsing red recording indicator and reclaim its 30px so the waveform bars fill the panel. Show recording duration (MM:SS) while recording/paused and transcription time (X.Xs) while processing, frozen on the brief success/error result. Also force the overlay hidden at startup: if a previous session was SIGKILLed mid-recording, the reused orphaned daemon would otherwise stay stuck visible until the next recording. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CZT7DuDus2VDvQKiGoqYcd
- systemd unit's ExecStartPre hard-required a wayland-* socket before
starting, so the service refused to run at all under an X11 session
(gnome-session-x11.target etc.). Accept an X11 socket
(/tmp/.X11-unix/X*) as an alternative readiness signal.
- _copy_text_to_clipboard/_restore_clipboard only tried wl-copy when the
binary existed on disk, not when a Wayland compositor was actually
reachable. On a hybrid X11/Wayland machine (wl-clipboard installed for
the Wayland session, but currently running X11) wl-copy exits 1 and
the code gave up instead of falling back to pyperclip, unlike
_save_clipboard which already had this fallback.
- pyperclip's own determine_clipboard() prefers a GObject-Introspection
GTK clipboard over xclip/xsel whenever `gi` is importable, and calls
gi.require_version('Gtk', '3.0') to get it. mic_osd's layer-shell probe
already pins this process's Gtk namespace to 4.0, so pyperclip's request
raised "Namespace Gtk is already loaded with version 4.0" the first time
the new clipboard fallback path ran. Force the xclip backend up front so
pyperclip never touches `gi`.
Hotkey capture (evdev/UInput), paste-key injection (ydotool), and window
detection (xdotool/xprop fallback) were already compositor-agnostic and
needed no changes. Tested end-to-end on GNOME/X11 (Ubuntu 24.04).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y87A3sADRj7eixj6ubiXnV
Owner
|
Whoa! Cool. I'll give this a review shortly. |
Owner
|
Thanks a lot for the PR 🎉 @ninyawee OK: the core changes for x11 support look good. But there are also some mic-osd visual/UX changes - were they included on purpose? I don't mind them, but they should be observed/understood on their own merits. Please split them out into a separate PR. Once that is done, it won't take long to merge in the x11 changes. |
…timers" This reverts commit d4a6489.
Owner
|
OK! Got this caught up @ninyawee please fork the OSD visualizer changes into another PR if you'd like. This is great - very much appreciated. |
Owner
|
Oh and @ninyawee PLEASE TEST! 🙏 |
Author
|
@goodroot hi Thanks for your hardworking on this project. I'm using every day. 🥰 |
Owner
|
ขอบคุณพี่ชายของฉัน |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
hyprwhspr already had most of the machinery to run compositor-agnostically (evdev/UInput hotkey capture, ydotool paste injection, xdotool/xprop window-detection fallback), but three things stopped it from actually working under X11:
hyprwhspr.service'sExecStartPrehard-required awayland-*socket in$XDG_RUNTIME_DIRbefore starting at all, so the service refused to even launch under an X11 session (e.g.gnome-session-x11.target). It now also accepts an X11 socket (/tmp/.X11-unix/X*) as a readiness signal._copy_text_to_clipboard/_restore_clipboardonly checked whether thewl-copybinary existed, not whether a Wayland compositor was actually reachable. On a hybrid X11/Wayland machine (wl-clipboard installed for when you're on Wayland, but currently running an X11 session)wl-copyexits 1 and the code gave up instead of falling back topyperclip— unlike_save_clipboard, which already had this fallback. Now both paths degrade the same way.pyperclip's owndetermine_clipboard()prefers a GObject-Introspection GTK clipboard overxclip/xselwhenevergiis importable, and callsgi.require_version('Gtk', '3.0')to get it. mic_osd's layer-shell availability probe already pins this same process'sGtknamespace to4.0, so pyperclip's request raisedNamespace Gtk is already loaded with version 4.0the first time the new clipboard fallback path actually ran. Fixed by forcing thexclipbackend explicitly at import time, so pyperclip never touchesgi.Test plan
hyprwhspr.servicewas silently crash-looping every ~17s under X11 before this fix (journalctl --user -u hyprwhspr.service, "Wayland socket not found")[READY]under X11, connects to the configured STT backend,NRestarts=0ERROR: Clipboard copy failed: Namespace Gtk already requires version 4.0,[ERROR] Text injection failed)xclipbackend, retested end-to-end:Super+Alt+D→ speak →Super+Alt+D→ transcript received → pasted successfully into the focused window, no errorsREADME's "Requires a Wayland session" line is left as-is in this PR — happy to update it (or soften to "Wayland recommended, X11 supported") if maintainers want, once there's more confidence across other X11 setups (KDE/X11, etc.) beyond the one this was tested on.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Y87A3sADRj7eixj6ubiXnV