ninjadev64
After upgrading to 2.5.1 all the input simulation buttons stopped working
I have been using input simulation to mimic various keyboard shortcuts for various application. After recent upgrade, they all stopped working. When I click on any of those keys, I see remote desktop window like this
After that, opendeck stops responding. I have to restart it.
Can you please let me know why this is happening
This is a security feature from Wayland. OpenDeck now supports native Wayland Apps for the input simulation. you need to allow the access for it to work.
This is a security feature from Wayland. OpenDeck now supports native Wayland Apps for the input simulation. you need to allow the access for it to work.
They said opendeck stops responding though, so they can't enable it it seems
I am also having input simulation problems after upgrading to 2.5.1
The following worked, now it does't: [k(Return),t("/hideout"), k(Return)] A simple macro to send me to my hideout in Path of Exile, doesn't work in game, doesn't work even when I have a text editor open.
running linux mint on X11
@pentamassiv - 2.5.1 is the update where the libei feature was enabled, because many people had issues without it, now it seems people have issues with it. Do you have any ideas?
Sorry for the late response but I am on X11. I don't have wayland.
To clarify further, I can flip the switch allowing the remote interaction and then click Share button. But, opendeck stops responding after that. When I restart opendeck, I have the same issue again!
Any workaround?
Sorry for the long no answer. The current Workaround will be to downgrade the Plugin to an older Version. I will prepare a HowTo after work today.
tldr; backup your config before updating to 2.5.1
It seems that the versioning of OpenDeck ist not "secmatic versioning", correct? After upgrading to 2.5.1 I could not simply go back to 2.5.0, because the configuration was made incompatible with the update. If the versioning was semantic versioning this should not happen. As far as I understand it at least.
You don't need to downgrade all of Opendeck. Its enough to Downgrade the Plugin. The dev @nekename already has a working Version of the Plugin from me. Also in 2.5.1 was no change and only one file needs to be changed to be able to use 2.5.0.
It seems that the versioning of OpenDeck ist not "secmatic versioning", correct? After upgrading to 2.5.1 I could not simply go back to 2.5.0, because the configuration was made incompatible with the update. If the versioning was semantic versioning this should not happen. As far as I understand it at least.
There is no incompatibility introduced, all you have to do is change the version field in settings.json back to 2.5.0. I don't introduce incompatibilities in minor version bumps and I do follow semver. It prevents you from downgrading regardless of the version. But, if you downgrade to 2.5.0, make sure to delete your starter pack plugin from the config directory, otherwise that won't be downgraded as well.
Sorry, but I don't know why it would hang.
It would be helpful to know what compositor they use (for example mutter/Gnome, wayfire, KDE, hyprland...). They could try running the enigo examples with different features activated to confirm that it is a bug with enigo. If the examples work, I think it's some kind of implementation bug in OpenDeck.
Sorry, but I don't know why it would hang.
It would be helpful to know what compositor they use (for example mutter/Gnome, wayfire, KDE, hyprland...). They could try running the enigo examples with different features activated to confirm that it is a bug with enigo. If the examples work, I think it's some kind of implementation bug in OpenDeck.
@pentamassiv For me its mutter/Gnome X11 on Arch Linux. I will try the examples over the weekend and report back.
Are you sure the compositor is using X11 on Gnome on Arch? The default is Wayland. The compositor uses XWayland if the application is using X11. For enigo it is only important if the compositor is using Wayland/XWayland or if it a X11 session
Are you sure the compositor is using X11 on Gnome on Arch? The default is Wayland. The compositor uses XWayland if the application is using X11. For enigo it is only important if the compositor is using Wayland/XWayland or if it a X11 session
Yes, Terrorwolf uses Xorg.
@pentamassiv We discovered that the issue is actually due to using it in another thread (I used std::thread::spawn to get around the tokio crash with libei I told you about). So it wasn't enabling libei that caused this, but rather a sort of side effect
Relevant source: https://github.com/nekename/OpenDeck/blob/main/plugins%2Fcom.amansprojects.starterpack.sdPlugin%2Fsrc%2Finput_simulation.rs
Oh, okay. Thank you for the clarification.
Is there something I can change on my side to prevent similar problems for other developers? I still haven't looked at the issue again. Hopefully I can do so within the next couple of weeks
Are you sure the compositor is using X11 on Gnome on Arch? The default is Wayland. The compositor uses XWayland if the application is using X11. For enigo it is only important if the compositor is using Wayland/XWayland or if it a X11 session
Wayland is disabled in the config file due to other Software Problems I have right now. So yeah its X11.
Oh, okay. Thank you for the clarification.
Is there something I can change on my side to prevent similar problems for other developers? I still haven't looked at the issue again. Hopefully I can do so within the next couple of weeks
Thanks for your help and sorry my response was a bit rushed earlier, I was on the move. We should only need to get "Issue 1" of https://github.com/enigo-rs/enigo/issues/453 resolved, then spawning a new thread shouldn't be necessary for libei support, and X11 will be happy too. You can use futures::executor::block_on or something similar to block on a future in any context regardless of whether it's in a Tokio runtime or not, so maybe look into that.
Thank you for the recommendation. It should be fixed now on the main branch
Thank you for the recommendation. It should be fixed now on the main branch
@pentamassiv I just tried it with a local build Version of enigo Main Branch in OpenDeck and got the same Problem as before.
I just tried the key.rs and the keyboard.rs examples. the key.rs worked, the other got the following Error: I used the same features in the Cargo.toml as in opendeck.
[2025-08-23T02:05:52Z ERROR enigo::platform::wayland] Failed to connect to Wayland. Try setting 'WAYLAND_DISPLAY=wayland-0'.
Start emulating
Start emulating
Start emulating
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623688
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623687
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623688
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623687
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623688
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623687
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623688
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623687
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623688
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623687
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623688
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623687
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623688
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623687
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623688
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623687
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623688
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623687
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623688
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] the serial 4 contained an invalid object with the id 18374686479671623687
[2025-08-23T02:05:55Z ERROR enigo::platform::libei] err reading
[2025-08-23T02:05:55Z ERROR enigo] simulating input failed: (unable to update the libei connection to scroll)
thread 'main' panicked at keyboard.rs:16:10:
called `Result::unwrap()` on an `Err` value: Simulate("unable to update the libei connection to scroll")
stack backtrace:
0: __rustc::rust_begin_unwind
at /rustc/29483883eed69d5fb4db01964cdf2af4d86e9cb2/library/std/src/panicking.rs:697:5
1: core::panicking::panic_fmt
at /rustc/29483883eed69d5fb4db01964cdf2af4d86e9cb2/library/core/src/panicking.rs:75:14
2: core::result::unwrap_failed
at /rustc/29483883eed69d5fb4db01964cdf2af4d86e9cb2/library/core/src/result.rs:1761:5
3: core::result::Result<T,E>::unwrap
at /home/jan/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:1167:23
4: keyboard::main
at ./keyboard.rs:16:10
5: core::ops::function::FnOnce::call_once
at /home/jan/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Thank you for the recommendation. It should be fixed now on the main branch
@pentamassiv I just tried it with a local build Version of enigo Main Branch in OpenDeck and got the same Problem as before.
You have to remove the usage of a separate thread in OpenDeck. The X11 problem seems to have been caused by that, and that was necessary for libei, and now on the main branch it isn't necessary anymore. You still have to remove it.
Thank you for testing it. I've never seen your invalid object error before. It looks like a separate problem though, because it happens after the libei connection was established. Could you please run the example like this:
RUST_LOG=debug REIS_DEBUG=1 cargo run --example keyboard --no-default-features --features libei_tokio
and paste the output?
Did this HowTo get published (https://github.com/nekename/OpenDeck/issues/120#issuecomment-3204776203)[here]
Did this HowTo get published (https://github.com/nekename/OpenDeck/issues/120#issuecomment-3204776203)[here]%5Bhere%5D)
I don't think so, but you can send me a message on Discord or Matrix and I can send you a patched Starterpack.
Hey, by the way, I forgot to update people here, @webtrend @gazhay @sebkir @bradmcminn82 - did this get at least partially fixed with v2.7.0 of the Starter Pack plugin? I think at least it shouldn't crash any more, even if the input simulation doesn't always work...
Is there a way to switch from libei to some local HID input like Solaar is doing it? Input simulation works in Wayland but you need to "Allow Remote Interaction". And this is not persistent. And if you click on the orange box in the sys-tray this sharing is stopped and OpenDeck is not asking again for permission.
