[Arch][Gnome][Kernel 6.12] Unable to create virtual input device

[ItzPrism]

Describe the bug

A clear and concise description of what the bug is.

Desktop (please complete the following information):

• Distro: Arch Linux
• Desktop Environment: Gnome
• output of uname -a: Linux eos 6.12.47-1-lts #1 SMP PREEMPT_DYNAMIC Fri, 12 Sep 2025 08:06:51 +0000 x86_64 GNU/Linux

Service Logs

Please copy the output of journalctl -u surface-dial.service / the daemon's stdout/stderr. -- no entries --

but, when manually run and run with stacktrace: thread '' panicked at src/fake_input.rs:121:14: failed to install virtual touchpad device: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" } note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

thread '' panicked at src/controller/controls/media_with_volume.rs:17:22: called Result::unwrap() on an Err value: RecvError

When possible, please reproduce the bug with the RUST_BACKTRACE=1 environment variable set. Having a detailed backtrace will make it easier to diagnose (and hopefully fix) the bug.

[daniel5151]

Sounds like you've got an evdev permissions issue.

Make sure you've followed the installation steps outlined in the README.md. Since you're on Arch, you'll need to adapt those steps to your particular install, as I don't have any hands on experience with Arch.

I'll leave this issue open for visibility. If you / someone else figures out the issue - please update the issue (and ideally - send in a PR that updates instructions for others)

[lukehowson]

I have exactly the same issue, but can suggest a hacky solution. I'm also on arch. linux 6.16.10-arch1-1, but hyprland under wayland rather than gnome.

I get the same error, and was ripping my hair out trying to figure it out. I was certain I had the right permissions. I ended up trying to step through it to see exactly what was doing it. But under a debugger it worked! The debug version runs without crashing: I suspect this is compiler-related rather than arch-related. If it's worth doing I can use an old version to see if that fixes it.

TLDR: Follow the rest of the install instructions, then, from the surface-dial-linux base directory: $ cargo build $ cp ./target/release/surface-dial-daemon ~/.cargo/bin/surface-dial-daemon

[daniel5151]

Yeah... if you look in the project's Cargo.toml file, you'll see that there are definitely some optimization-related issues in one (or more?) of the dependencies this project uses.

It's been a while since I've daily-driven linux as my primary desktop OS, so I don't have a great way to iterate on surface-dial-linux myself... but if someone wants to try bumping some dependency versions / swapping out certain deps for more stable equivalent ones - I'd be happy to review and merge and PR sent my way :)