games-on-whales/wolf

Fork 0

mirror of https://github.com/games-on-whales/wolf.git synced 2026-10-15 21:12:08 +00:00

[GH-ISSUE #451] DualSense input leaks into host #277

New issue

Closed

opened 2026-10-15 12:59:16 +00:00 by bsakaguchi · 7 comments

bsakaguchi commented

2026-10-15 12:59:16 +00:00

Owner

Originally created by @lyubomirv on GitHub (Jun 30, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/451

Host system:
OS: Arch
DE: Gnome, on Wayland
GPU: Rx 7900 XT
Monitors: 2 monitors

Client:
Chromecast with Google TV
DualSense controller

I'm running Wolf and have two apps installed - Steam and Heroic. Initially I've noticed that when I'm playing a game the controller's touchpad (which works fine in the game) also controls the mouse pointer on the host. When testing further using a browser-based gamepad tester, I actually see that I get all input from the controller on my host's desktop.

I initially saw this in the Heroic app and thought that it might be something related to it but then tested Steam as well and even just the Wolf UI - it's all the same. I can see the DualSense being detected as a Wolf DualSense by the testing web page on the host as soon as I open the Wolf UI app in Moonlight, and disconnected as soon as I close it.

I thought input should be isolated, so am I doing something wrong?

The only settings that I've changed in the TOML config file are:

The name of the host
Force the controller to be a PS one for the first client
Map the host dirs where my Steam/Heroic games are installed for those app containers

Originally created by @lyubomirv on GitHub (Jun 30, 2026). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/451 Host system: OS: Arch DE: Gnome, on Wayland GPU: Rx 7900 XT Monitors: 2 monitors Client: Chromecast with Google TV DualSense controller I'm running Wolf and have two apps installed - Steam and Heroic. Initially I've noticed that when I'm playing a game the controller's touchpad (which works fine in the game) also controls the mouse pointer on the host. When testing further using a browser-based gamepad tester, I actually see that I get all input from the controller on my host's desktop. I initially saw this in the Heroic app and thought that it might be something related to it but then tested Steam as well and even just the Wolf UI - it's all the same. I can see the DualSense being detected as a Wolf DualSense by the testing web page on the host as soon as I open the Wolf UI app in Moonlight, and disconnected as soon as I close it. I thought input should be isolated, so am I doing something wrong? The only settings that I've changed in the TOML config file are: - The name of the host - Force the controller to be a PS one for the first client - Map the host dirs where my Steam/Heroic games are installed for those app containers

bsakaguchi closed this issue

2026-10-15 12:59:17 +00:00

bsakaguchi commented

2026-10-15 12:59:17 +00:00

Author

Owner

@JBailes commented on GitHub (Jun 30, 2026):

See https://github.com/games-on-whales/unraid-plugin/issues/57 for other reports of this.

@JBailes commented on GitHub (Jun 30, 2026): See https://github.com/games-on-whales/unraid-plugin/issues/57 for other reports of this.

bsakaguchi commented

2026-10-15 12:59:17 +00:00

Author

Owner

@lyubomirv commented on GitHub (Jun 30, 2026):

I'm not sure this is the same. I'm not using unraid, and I'm not experiencing leaking from apps into wolf ui and starting other apps. Of course, it might still be the same issue, though, just saying.

@lyubomirv commented on GitHub (Jun 30, 2026): I'm not sure this is the same. I'm not using unraid, and I'm not experiencing leaking from apps into wolf ui and starting other apps. Of course, it might still be the same issue, though, just saying.

bsakaguchi commented

2026-10-15 12:59:17 +00:00

Author

Owner

@ABeltramo commented on GitHub (Jun 30, 2026):

Have you added the udev rules as described in the quickstart guide? With those applied, the joypads will only be available to root and it'll block access to any other user effectively achieving isolation. Unless you log in your system as root that is..

@ABeltramo commented on GitHub (Jun 30, 2026): Have you added the udev rules as described in the [quickstart guide](https://games-on-whales.github.io/wolf/stable/user/quickstart.html#_virtual_devices_support)? With those applied, the joypads will only be available to `root` and it'll block access to any other user effectively achieving isolation. Unless you log in your system as `root` that is..

bsakaguchi commented

2026-10-15 12:59:17 +00:00

Author

Owner

@lyubomirv commented on GitHub (Jul 1, 2026):

Yes, I have. And I am not logging into my desktop as root.

However, what I noticed back when I added those rules, is that it was a kind of an odd location for my system. The directory /etc/udev/rules.d/ was completely empty and these rules file was the first thing I added. I remembered that Sunshine also has some similar rules file and found that it is located in /usr/lib/udev/rules.d/ - where I found a huge amount of other rules files. So this seemed like the proper location.
I tried moving the wolf rules there but it was exactly the same.

Then I noticed that the web-page gamepad tester on the host detects the DualSense controller as "Wolf DualSense (virtual) pad". However, in the rules file it is described as "Wolf PS5 (virtual) pad". I assume that this string is how it determines which device to apply the rule for, so I changed the strings in the rules file (both the kernel hidraw and the subsystems input ones) to match what the controller tester detected it as (changed the part "PS5" -> "DualSense").

And this worked!

Well... at least for the regular controls - the gamepad tester no longer picks up the controller, so it doesn't detect any of the button presses, axes, etc. However, the DualSense touchpad still moves the mouse on the desktop, and I can click things around. I looked through Moonlight's settings but don't see anything particular regarding the controller touchpad, so I'm guessing the DualSense is maybe treated also as a virtual mouse, and the rules don't cover that? Does that make any sense?

I've also tried moving the rules file between the two mentioned locations on my system, and it seems to make no difference, so I've left it in /etc/udev/rules.d/ as the documentation says.

So, I guess two things come out of this:

The rules file in the documentation should be updated with the proper string for DualSense - assuming that this is how it would appear on all systems (if not, maybe a way of detecting it and instructing the user what to put there).
Find out why the DualSense touchpad still leaks through to the host desktop.

@lyubomirv commented on GitHub (Jul 1, 2026): Yes, I have. And I am not logging into my desktop as root. However, what I noticed back when I added those rules, is that it was a kind of an odd location for my system. The directory `/etc/udev/rules.d/` was completely empty and these rules file was the first thing I added. I remembered that Sunshine also has some similar rules file and found that it is located in `/usr/lib/udev/rules.d/` - where I found a huge amount of other rules files. So this seemed like the proper location. I tried moving the wolf rules there but it was exactly the same. Then I noticed that the web-page gamepad tester on the host detects the DualSense controller as `"Wolf DualSense (virtual) pad"`. However, in the rules file it is described as `"Wolf PS5 (virtual) pad"`. I assume that this string is how it determines which device to apply the rule for, so I changed the strings in the rules file (both the kernel hidraw and the subsystems input ones) to match what the controller tester detected it as (changed the part "PS5" -> "DualSense"). **And this worked!** Well... at least for the regular controls - the gamepad tester no longer picks up the controller, so it doesn't detect any of the button presses, axes, etc. However, the DualSense touchpad **still moves the mouse** on the desktop, and I can click things around. I looked through Moonlight's settings but don't see anything particular regarding the controller touchpad, so I'm guessing the DualSense is maybe treated also as a virtual mouse, and the rules don't cover that? Does that make any sense? I've also tried moving the rules file between the two mentioned locations on my system, and it seems to make no difference, so I've left it in `/etc/udev/rules.d/` as the documentation says. So, I guess two things come out of this: - The rules file in the documentation should be updated with the proper string for DualSense - assuming that this is how it would appear on all systems (if not, maybe a way of detecting it and instructing the user what to put there). - Find out why the DualSense touchpad still leaks through to the host desktop.

bsakaguchi commented

2026-10-15 12:59:17 +00:00

Author

Owner

@lyubomirv commented on GitHub (Jul 3, 2026):

Looking at the code here:

github.com/games-on-whales/wolf@d6d41dec9c/src/moonlight-server/control/input_handler.cpp (L126)

Seems like the controller is created with "DualSense" in its name, not "PS5", so I guess the rules file in the docs should be updated. I can do that later or over the weekend and make a pull request if that's ok?

@lyubomirv commented on GitHub (Jul 3, 2026): Looking at the code here: https://github.com/games-on-whales/wolf/blob/d6d41dec9cf758b086768e19a7dc02c20ffce22c/src/moonlight-server/control/input_handler.cpp#L126 Seems like the controller is created with "DualSense" in its name, not "PS5", so I guess the rules file in the docs should be updated. I can do that later or over the weekend and make a pull request if that's ok?

bsakaguchi commented

2026-10-15 12:59:18 +00:00

Author

Owner

@JBailes commented on GitHub (Jul 6, 2026):

Fixed in https://github.com/games-on-whales/wolf/pull/455

Keep an eye on 455, @lyubomirv

@JBailes commented on GitHub (Jul 6, 2026): Fixed in https://github.com/games-on-whales/wolf/pull/455 Keep an eye on 455, @lyubomirv

bsakaguchi commented

2026-10-15 12:59:18 +00:00

Author

Owner

@lyubomirv commented on GitHub (Jul 13, 2026):

Thank you! That would be the better fix, so closing this.

@lyubomirv commented on GitHub (Jul 13, 2026): Thank you! That would be the better fix, so closing this.