fix(wayland): initialise Enigo, and tolerate failure#1337
Conversation
Enigo is used as a fallback, but prior to this change, if it failed to
initialise paste() would never invoke the primary paste method. Instead
the following logs would be observed:
[2026-04-26][23:56:08][handy_app_lib::clipboard][INFO] Using paste method: Direct, delay: 60ms
[2026-04-26][23:56:08][handy_app_lib::clipboard][ERROR] Enigo state not initialized
[2026-04-26][23:56:08][handy_app_lib::actions][ERROR] Failed to paste transcription: Enigo state not initialized
...since paste()'s call to AppHandle::try_state() would return an error
which would be propagated up, causing an early exit.
|
Only question I have is, do we have a clear reason why Enigo is failing to initialize? Is there an upstream bug that can be fixed? I think we probably should tolerate a failure like you have, but I would prefer to fix upstream as well if possible. What I mean by upstream in this case, is something in the code not initializing Enigo when it should? Or is it a true failure and why is it failing? |
|
sorry,+ 1 to ones who expecting problems with "paste" on wayland/kubuntu_lts_24.04 right now |
|
Looks like it's trying to use its After enabling the crate's Unclear why, but the wayland impl depends on |
|
Interesting okay. I think we have not enabled Wayland as a feature as I believe it was marked experimental or had some chances of breaking things for other users, would need more widespread testing on it before release |
|
As far as I can tell Enigo doesn't use the An unrelated idea I had that may be useful was to have the PR workflow produce binaries, so once you've approved the workflow run we could direct users at those unstable builds without having them need to have a working Rust toolchain. The flake makes it easy for Nix users, but I'm aware we are the minority. I can have a go at doing this in a fork if you like. |
|
There's already one for this :) |
LukeCarrier
changed the title
new ubuntu LTS comes without x11 at all, so please, take care of this env =) |
I know you want to see this fixed, but please don't pile on the maintainer leaving comments which are neither actionable nor particularly constructive. You can 👍 the PR to show interest, you don't need to keep spamming the maintainer and I. |
|
I've been running this branch for the past few days and can confirm it works perfectly on wayland (niri, nixos). Handy did not work at all before this fix for me (enigo init failure, same as reported here). I don't really have any non-wayland setups to run it from, but on this side it works perfectly! |
|
Oh nice I had this or a very similar issue on main release using arch linux and niri. Codex 5.5 suggested using xwayland-satellite and adding a small fake display to my config, then Enigo finds that and the flow I actually use (that shouldn't require Enigo at all) is able to continue. I'll test this branch and see if I can repro/it fixes my issue as well. Update: @LukeCarrier's patch fixes my issue as well. Summary from codex: The important part of the new log is:
DisplayParsingError(DisplayNotSet)
failed to establish x11 connection
Enigo initialized successfully after permission grant
...
Using paste method: Direct, delay: 60ms
Using user-specified wtype
Text pasted successfully in 110.795336ms
That means:
- DISPLAY was still unset
- X11 init still failed, as expected
- the patched Enigo path tolerated that instead of aborting
- Handy continued on the Wayland path
- it used wtype
- paste succeeded
Your test transcript was:
Testing my audio stuff.
So this confirms the LukeCarrier fix addresses the real issue we were seeing on niri Wayland. The upstream report back to Handy can be pretty strong now: with
the patched build, pure Wayland works without needing the xwayland-satellite workaround to get past Enigo state not initialized.``` |
5 participants
Enable the
enigocrate'swaylandfeature. Without it, despiteWAYLAND_DISPLAYbeing set, Enigo tries only itsx11rbbackend rather thanwayland:In this configuration Enigo will try both the `x11rb` and `wayland` backends, but only the `wayland` one will succeed:
Enigo is used as a fallback, but prior to this change, if it failed to initialise
paste()would never invoke the primary paste method. Instead the following logs would be observed:...since paste()'s call to
AppHandle::try_state()would return an error which would be propagated up, causing an early exit.Before Submitting This PR
Please confirm you have done the following:
If this is a feature or change that was previously closed/rejected:
Human Written Description
Enigo is used as a fallback, but prior to this change, if it failed to initialise
paste()would never invoke the primary paste method. Instead the following logs would be observed:...since
paste()'s call toAppHandle::try_state()would return an error which would be propagated up, causing an early exit.Happy to switch to doing early returns rather than
if let Some(x)s if you prefer, as it would reduce the size of the diff, but I thought it made the code easier to read.Related Issues/Discussions
Fixes #
Discussion:
Community Feedback
Testing
Screenshots/Videos (if applicable)
AI Assistance
If AI was used:
paste()propagating that error, but figuring out the correct fix for the mutex took a bit of back and forth.