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 #264] Server side PS5 controller not detected unless Privileged: true #182

New issue

Closed

opened 2026-10-15 12:57:46 +00:00 by bsakaguchi · 5 comments

bsakaguchi commented

2026-10-15 12:57:46 +00:00

Owner

Originally created by @ironoa on GitHub (Oct 10, 2025).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/264

First of all, thanks for this amazing project !

I am having an issue connecting a (ps5) controller on the server, instead of having it streamed from the Moonlight client.

TL;DR, The quick fix to have it working: config.toml -> Steam's [apps.runner] -> HostConfig -> "Privileged": true instead of the default false.
But I'm not sure this is the expected way to have it running, plus Privileged": true never sounds right I guess.

On the server (Ubuntu server 24.04, headless) the controller is properly detected (/dev/inputs/js0, js1, event9, event10) and receives inputs (tested with jstest).
On the wolf's container the controller is properly detected (/dev/inputs/js0, js1, event9, event10) and receives inputs (tested with jstest, installed inside the container). Just to be clear, even with Privileged": false, though that setting acts on the subsequently spawned container only.
On the WolfSteam_xxx's container the controller is properly detected (/dev/inputs/js0, js1, event9, event10) and receives inputs (tested with jstest, installed inside the container) iff the above mentioned Privileged": true is set. => server side controller can be used to play only if Privileged": true is set. Otherwise, js0, js1, event9, event10 don't even show up in /dev/inputs/.

Tested with:

Docker Nvidia(Manual) method from the Quickstart
straight Docker CLI command taken from the documentation:

docker run \
    --name wolf \
    --network=host \
    -e NVIDIA_DRIVER_VOLUME_NAME=nvidia-driver-vol \
    -v nvidia-driver-vol:/usr/nvidia:rw \
    -v /etc/wolf:/etc/wolf:rw \
    -v /var/run/docker.sock:/var/run/docker.sock:rw \
    --device /dev/nvidia-uvm \
    --device /dev/nvidia-uvm-tools \
    --device /dev/dri/ \
    --device /dev/nvidia-caps/nvidia-cap1 \
    --device /dev/nvidia-caps/nvidia-cap2 \
    --device /dev/nvidiactl \
    --device /dev/nvidia0 \
    --device /dev/nvidia-modeset \
    --device /dev/uinput \
    --device /dev/uhid \
    -v /dev/:/dev/:rw \
    -v /run/udev:/run/udev:rw \
    --device-cgroup-rule "c 13:* rmw" \
    ghcr.io/games-on-whales/wolf:stable

I tired also the Virtual devices support section; not sure it's relevant though: strictly following the documentation, wolf is run as root anyway, no ?
current ghcr.io/games-on-whales/wolf:stable image is sha-2984c2b
Ubuntu 24.04.3 LTS, server, headless, Docker version 28.5.0, build 887030f
| NVIDIA-SMI 580.65.06 Driver Version: 580.65.06 CUDA Version: 13.0 |

Maybe related, maybe another issue: I noticed that if the server side controller gets disconnected while Steam (and the streaming session) is active, reconnecting the controller won't make it be detected again... one needs to restart Steam unfortunately (basically, the WolfSteam_xxx container needs to die and get recreated)

Maybe related, maybe another issue: if one restarts the WolfSteam_xxx container (docker restart WolfSteam_xxx) manually/directly, the contents of the ..../Steam folder (i.e. /etc/wolf/common/Steam) gets wiped ! tested with both "Privileged": true and "Privileged": false.

Originally created by @ironoa on GitHub (Oct 10, 2025). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/264 First of all, thanks for this amazing project ! I am having an issue connecting a (ps5) controller on the server, instead of having it streamed from the Moonlight client. **TL;DR, The quick fix to have it working**: `config.toml -> Steam's [apps.runner] -> HostConfig -> "Privileged": true` instead of the default false. But I'm not sure this is the expected way to have it running, plus `Privileged": true` never sounds right I guess. --- - On the server (Ubuntu server 24.04, headless) the controller is properly detected (/dev/inputs/js0, js1, event9, event10) and receives inputs (tested with jstest). - On the wolf's container the controller is properly detected (/dev/inputs/js0, js1, event9, event10) and receives inputs (tested with jstest, installed inside the container). Just to be clear, even with `Privileged": false`, though that setting acts on the subsequently spawned container only. - On the WolfSteam_xxx's container the controller is properly detected (/dev/inputs/js0, js1, event9, event10) and receives inputs (tested with jstest, installed inside the container) **iff the above mentioned `Privileged": true` is set**. => server side controller can be used to play only if `Privileged": true` is set. Otherwise, js0, js1, event9, event10 don't even show up in `/dev/inputs/`. Tested with: - Docker Nvidia(Manual) method from the [Quickstart](https://games-on-whales.github.io/wolf/stable/user/quickstart.html#_docker) - straight Docker CLI command taken from the documentation: ```bash docker run \ --name wolf \ --network=host \ -e NVIDIA_DRIVER_VOLUME_NAME=nvidia-driver-vol \ -v nvidia-driver-vol:/usr/nvidia:rw \ -v /etc/wolf:/etc/wolf:rw \ -v /var/run/docker.sock:/var/run/docker.sock:rw \ --device /dev/nvidia-uvm \ --device /dev/nvidia-uvm-tools \ --device /dev/dri/ \ --device /dev/nvidia-caps/nvidia-cap1 \ --device /dev/nvidia-caps/nvidia-cap2 \ --device /dev/nvidiactl \ --device /dev/nvidia0 \ --device /dev/nvidia-modeset \ --device /dev/uinput \ --device /dev/uhid \ -v /dev/:/dev/:rw \ -v /run/udev:/run/udev:rw \ --device-cgroup-rule "c 13:* rmw" \ ghcr.io/games-on-whales/wolf:stable ``` - I tired also the [Virtual devices support](https://games-on-whales.github.io/wolf/stable/user/quickstart.html#_virtual_devices_support) section; not sure it's relevant though: strictly following the documentation, wolf is run as root anyway, no ? - current `ghcr.io/games-on-whales/wolf:stable` image is [sha-2984c2b](https://github.com/games-on-whales/wolf/pkgs/container/wolf/527375596?tag=sha-2984c2b) - `Ubuntu 24.04.3 LTS, server, headless`, `Docker version 28.5.0, build 887030f` - `| NVIDIA-SMI 580.65.06 Driver Version: 580.65.06 CUDA Version: 13.0 |` --- Maybe related, maybe another issue: I noticed that if the server side controller gets disconnected while Steam (and the streaming session) is active, reconnecting the controller won't make it be detected again... one needs to restart Steam unfortunately (basically, the WolfSteam_xxx container needs to die and get recreated) Maybe related, maybe another issue: if one restarts the WolfSteam_xxx container (`docker restart WolfSteam_xxx`) manually/directly, the contents of the `..../Steam` folder (i.e. `/etc/wolf/common/Steam`) gets wiped ! tested with both `"Privileged": true` and `"Privileged": false`.

bsakaguchi

2026-10-15 12:57:46 +00:00

closed this issue
added the
question
label

bsakaguchi commented

2026-10-15 12:57:48 +00:00

Author

Owner

@ABeltramo commented on GitHub (Oct 10, 2025):

We've gone to great lengths to properly isolate virtual devices between containers to avoid games picking up joypads that are in other sessions (or on the host) in order to support multiple users, so this is definitely working as intended 😅

Setting a container to Privileged will break all that and will allow the container to access and see the devices on your host, amongst other things..

Can you share a bit more about your use case? Why are you plugging the joypad in your server instead of in the client? Maybe we can find a better alternative, so that also hot-plugging will work.

@ABeltramo commented on GitHub (Oct 10, 2025): We've gone to great lengths to properly isolate virtual devices between containers to avoid games picking up joypads that are in other sessions (or on the host) in order to support multiple users, so this is definitely working as intended 😅 Setting a container to `Privileged` will break all that and will allow the container to access and see the devices on your host, amongst other things.. Can you share a bit more about your use case? Why are you plugging the joypad in your server instead of in the client? Maybe we can find a better alternative, so that also hot-plugging will work.

bsakaguchi commented

2026-10-15 12:57:48 +00:00

Author

Owner

@ironoa commented on GitHub (Oct 10, 2025):

We've gone to great lengths to properly isolate virtual devices between containers to avoid games picking up joypads that are in other sessions (or on the host) in order to support multiple users, so this is definitely working as intended 😅

Got it, makes sense. If you tell me that the server side controller is an anti pattern, I can try to avoid that kind of approach.

Why are you plugging the joypad in your server instead of in the client?

The input lag is just noticeably better when the controller is connected to the server, so whenever possible I try to go down that route. By better I mean: input lag constantly/reliably almost zero. When passed via Moonlight (tested with mac os client, web os lg tv client), the lag is a bit higher, and with some sudden high delay spikes sometimes. Connection wise:

server <-> (10 Gbps ethernet) router <-> (250 Mbps ethernet) tv
server <-> (ethernet) router <-> (wifi 5 GHz) macbook
controller <-> macbook : bluetooth
controller <-> tv : bluetooth. This is a bit painful for me, since I needed to install a custom ipk for Web OS to be able to connect the controller directly to the TV (LG C series); bluetooth controllers are natively supported by Web OS from 2021 year models only
controller <-> server: bluetooth
so far all my tests are lan only

Furthermore, maybe related, maybe another issue: it happened to me a couple of times only (just tested and I couldn't replicate). When the PS5 controller is passed from Moonlight (detected as DualSense Wireless Controller by the Steam Controller settings), if the controller loses connection and then it gets reconnected, it is then detected as PS5 Controller (different name), and all the buttons mappings are flipped/broken/unusable. Even in that case, one needs to restart Steam.

In any case thanks, my setup is very usable at the moment, I am just trying to optimize (latency, security, ...) and better understand the project. FYI I just happily migrated away from a Windows 11 VM with Apollo: that setup was working great, but needed Windows 😅

I tired also the Virtual devices support section; not sure it's relevant though: strictly following the documentation, wolf is run as root anyway, no ?

A clarification: is that actually some old documentation that shouldn't be followed anymore ? shall we remove that section then ?

@ironoa commented on GitHub (Oct 10, 2025): >> We've gone to great lengths to properly isolate virtual devices between containers to avoid games picking up joypads that are in other sessions (or on the host) in order to support multiple users, so this is definitely working as intended 😅 Got it, makes sense. If you tell me that the server side controller is an anti pattern, I can try to avoid that kind of approach. >> Why are you plugging the joypad in your server instead of in the client? The input lag is just noticeably better when the controller is connected to the server, so whenever possible I try to go down that route. By better I mean: input lag constantly/reliably almost zero. When passed via Moonlight (tested with mac os client, web os lg tv client), the lag is a bit higher, and with some sudden high delay spikes sometimes. Connection wise: - server <-> (10 Gbps ethernet) router <-> (250 Mbps ethernet) tv - server <-> (ethernet) router <-> (wifi 5 GHz) macbook - controller <-> macbook : bluetooth - controller <-> tv : bluetooth. This is a bit painful for me, since I needed to install a custom ipk for Web OS to be able to connect the controller directly to the TV (LG C series); bluetooth controllers are [natively supported by Web OS from 2021 year models only](https://www.lg.com/us/support/help-library/how-to-set-up-a-game-controller-for-webos-gaming--20152528678452OLT#comp_dev) - controller <-> server: bluetooth - so far all my tests are lan only Furthermore, maybe related, maybe another issue: it happened to me a couple of times only (just tested and I couldn't replicate). When the PS5 controller is passed from Moonlight (detected as `DualSense Wireless Controller` by the Steam Controller settings), if the controller loses connection and then it gets reconnected, it is then detected as `PS5 Controller` (different name), and all the buttons mappings are flipped/broken/unusable. Even in that case, one needs to restart Steam. In any case thanks, my setup is very usable at the moment, I am just trying to optimize (latency, security, ...) and better understand the project. FYI I just happily migrated away from a Windows 11 VM with [Apollo](https://github.com/ClassicOldSong/Apollo): that setup was working great, but needed Windows 😅 >> I tired also the [Virtual devices support](https://games-on-whales.github.io/wolf/stable/user/quickstart.html#_virtual_devices_support) section; not sure it's relevant though: strictly following the documentation, wolf is run as root anyway, no ? A clarification: is that actually some old documentation that shouldn't be followed anymore ? shall we remove that section then ?

bsakaguchi commented

2026-10-15 12:57:49 +00:00

Author

Owner

@ABeltramo commented on GitHub (Oct 10, 2025):

Got it, makes sense. If you tell me that the server side controller is an anti pattern, I can try to avoid that kind of approach.

It is if you care about the multi-user functionality, if not, you are free to do as you like! 😉

Furthermore, maybe related, maybe another issue: it happened to me a couple of times only (just tested and I couldn't replicate). When the PS5 controller is passed from Moonlight (detected as DualSense Wireless Controller by the Steam Controller settings), if the controller loses connection and then it gets reconnected, it is then detected as PS5 Controller (different name), and all the buttons mappings are flipped/broken/unusable. Even in that case, one needs to restart Steam.

I know what's going on, we just set a random Mac address for our virtual devices. We've recently pushed a fix for Sunshine that I should probably backport to Wolf too; can you open up a different issue for this so that we don't forget about it?

I tired also the Virtual devices support section; not sure it's relevant though: strictly following the documentation, wolf is run as root anyway, no ?

A clarification: is that actually some old documentation that shouldn't be followed anymore ? shall we remove that section then ?

That definitely needs updating, for example we don't create virtual mouse/keyboard devices anymore. Wolf currently runs as root but I would like to go back to an unprivileged user sooner or later and the only way to achieve that is via some good udev rules

@ABeltramo commented on GitHub (Oct 10, 2025): > Got it, makes sense. If you tell me that the server side controller is an anti pattern, I can try to avoid that kind of approach. > It is if you care about the multi-user functionality, if not, you are free to do as you like! 😉 > Furthermore, maybe related, maybe another issue: it happened to me a couple of times only (just tested and I couldn't replicate). When the PS5 controller is passed from Moonlight (detected as `DualSense Wireless Controller` by the Steam Controller settings), if the controller loses connection and then it gets reconnected, it is then detected as `PS5 Controller` (different name), and all the buttons mappings are flipped/broken/unusable. Even in that case, one needs to restart Steam. > I know what's going on, we just set a random Mac address for our virtual devices. We've recently pushed a fix for Sunshine that I should probably backport to Wolf too; can you open up a different issue for this so that we don't forget about it? > >> I tired also the [Virtual devices support](https://games-on-whales.github.io/wolf/stable/user/quickstart.html#_virtual_devices_support) section; not sure it's relevant though: strictly following the documentation, wolf is run as root anyway, no ? > > A clarification: is that actually some old documentation that shouldn't be followed anymore ? shall we remove that section then ? That definitely needs updating, for example we don't create virtual mouse/keyboard devices anymore. Wolf currently runs as root but I would like to go back to an unprivileged user sooner or later and the only way to achieve that is via some good udev rules

bsakaguchi commented

2026-10-15 12:57:49 +00:00

Author

Owner

@ironoa commented on GitHub (Oct 12, 2025):

A clarification: is that actually some old documentation that shouldn't be followed anymore ? shall we remove that section then ?

That definitely needs updating, for example we don't create virtual mouse/keyboard devices anymore. Wolf currently runs as root but I would like to go back to an unprivileged user sooner or later and the only way to achieve that is via some good udev rules

I agree, ideally it should run as non root with the udev rules. Let me know if you want me to open a reminder issue even for that topic.

@ironoa commented on GitHub (Oct 12, 2025): > > A clarification: is that actually some old documentation that shouldn't be followed anymore ? shall we remove that section then ? > > That definitely needs updating, for example we don't create virtual mouse/keyboard devices anymore. Wolf currently runs as root but I would like to go back to an unprivileged user sooner or later and the only way to achieve that is via some good udev rules I agree, ideally it should run as non root with the udev rules. Let me know if you want me to open a reminder issue even for that topic.

bsakaguchi commented

2026-10-15 12:57:49 +00:00

Author

Owner

@ABeltramo commented on GitHub (Oct 12, 2025):

There's a bit of discussion about the udev rules here already https://github.com/games-on-whales/wolf/issues/193

@ABeltramo commented on GitHub (Oct 12, 2025): There's a bit of discussion about the udev rules here already https://github.com/games-on-whales/wolf/issues/193