Choose between xdo and wayland at runtime

[Yamakaky]

Describe the bug
On linux, enigo supports xdo, libei and wayland. I would assume that one is chosen at runtime with some kind of (user configurable?) priority. However, it currently initializes all the featured runtimes, and uses them in parallel for keyboard/mouse control.

Affected code:

• new : https://docs.rs/enigo/0.2.0/src/enigo/linux/mod.rs.html#55
• Mouse/Keyboard implementation : https://docs.rs/enigo/0.2.0/src/enigo/linux/mod.rs.html#161-403

One consequence (and how I found out about this): set_delay is always applied, even on wayland which doesn't need it.

[2024-05-10T09:24:52Z DEBUG enigo] using default settings
[2024-05-10T09:24:52Z DEBUG enigo::platform::wayland] trying to establish a connection to $WAYLAND_DISPLAY
[2024-05-10T09:24:52Z DEBUG enigo::platform::keymap] regenerated the keymap
[2024-05-10T09:24:52Z WARN  enigo::platform::wayland] Got a seat event Capabilities { capabilities: Value(Capability(Pointer | Keyboard)) }
[2024-05-10T09:24:52Z DEBUG enigo::platform] wayland connection established
[2024-05-10T09:24:52Z DEBUG enigo::platform] trying to establish a x11 connection to $DISPLAY
[2024-05-10T09:24:52Z DEBUG enigo::platform::x11] using xdo
[2024-05-10T09:24:52Z DEBUG enigo::platform] x11 connection established
...
2024-05-10T09:45:17Z DEBUG enigo::platform] added the key Space to the held keys
[2024-05-10T09:45:17Z DEBUG enigo::platform] entered the key
[2024-05-10T09:45:17Z DEBUG enigo::platform] key(key: Space, direction: Release)
[2024-05-10T09:45:17Z DEBUG enigo::platform::keymap] keymap did not change and does not require regeneration
[2024-05-10T09:45:17Z WARN  enigo::platform::wayland] Got a input method event TextChangeCause { cause: Value(InputMethod) }
[2024-05-10T09:45:17Z WARN  enigo::platform::wayland] Got a input method event ContentType { hint: Value(ContentHint(0x0)), purpose: Value(Terminal) }
[2024-05-10T09:45:17Z WARN  enigo::platform::wayland] Got a input method event Done
[2024-05-10T09:45:17Z WARN  enigo::platform::wayland] Got a input method event TextChangeCause { cause: Value(InputMethod) }
[2024-05-10T09:45:17Z WARN  enigo::platform::wayland] Got a input method event ContentType { hint: Value(ContentHint(0x0)), purpose: Value(Terminal) }
[2024-05-10T09:45:17Z WARN  enigo::platform::wayland] Got a input method event Done
[2024-05-10T09:45:17Z DEBUG enigo::platform::keymap] removed the key 8 from the held keycodes
[2024-05-10T09:45:17Z DEBUG enigo::platform] entered the key via wayland
[2024-05-10T09:45:17Z DEBUG enigo::platform::x11] xdo_send_keysequence_window_up with string "space", delay 100000
[2024-05-10T09:45:17Z DEBUG enigo::platform] entered the key via x11
[2024-05-10T09:45:17Z DEBUG enigo::platform] removed the key Space from the held keys
[2024-05-10T09:45:17Z DEBUG enigo::platform] entered the key
[2024-05-10T09:45:17Z DEBUG enigo::platform] key(key: Space, direction: Press)
[2024-05-10T09:45:17Z DEBUG enigo::platform::keymap] keymap did not change and does not require regeneration
[2024-05-10T09:45:17Z WARN  enigo::platform::wayland] Got a input method event TextChangeCause { cause: Value(InputMethod) }

To Reproduce
I assume you need a wayland environment with xwayland enabled. I use Sway.

Expected behavior
I would expect enigo to pick one backend at runtime. Quickfix seems to be to modify new() to return as soon as one backend successfully initializes.

Environment (please complete the following information):

• OS: Linux - sway - wayland with xwayland
• Rust 1.77
• Library Version 0.2.0

[pentamassiv]

Thank you for your report. The thing is, sometimes it is not enough to use the Wayland protocols and you have to use Wayland and X11.

I am not super happy about the implementation which backend is being used. You are right, it can definately be improved. If you are sure X11 is not needed, you can compile enigo without X11 support to avoid the occasional sleep. Of course that is just a hack and will not be a solution if you do not know what users of your program are using.

I'll leave this issue open as a reminder, but am too busy the next months to actively work on it.