[GH-ISSUE #414] Dualsense Adaptive Triggers not working #273

New issue

Closed

opened 2026-10-15 12:59:05 +00:00 by bsakaguchi · 24 comments

bsakaguchi commented 2026-10-15 12:59:05 +00:00

Owner

Copy link

Originally created by @Masong19hippows on GitHub (May 28, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/414

Hey,

So I use a Dualsense controller connected to wolf within a Proxmox VM. Basic controller functions work fine, however some of the features like adaptive triggers and the touchpad don't work. I have tried numerous combinations with forwarding inputs and messing with privileged vs unprivileged containers. I have tested with dualsensectl for the most part.

Before I dive any deeper, I want to confirm that these things are supposed to work. I can't find any good documentation to confirm or deny this. I have also attached my configs below in case you see an obvious issue.

docker-compose.yml:

services:
  wolf:
    image: ghcr.io/games-on-whales/wolf:stable
    environment:
      # Add this line
      - WOLF_SOCKET_PATH=/var/run/wolf/wolf.sock
      - WOLF_LOG_LEVEL=DEBUG
    volumes:
      - ./wolf:/etc/wolf
      - /usr/bin/dualsensectl:/usr/bin/dualsensectl
      - /var/run/docker.sock:/var/run/docker.sock:rw
      - /dev/:/dev/:rw
      - /run/udev:/run/udev:rw
      - /var/run/wolf:/var/run/wolf
    device_cgroup_rules:
      - 'c 13:* rmw'
    devices:
      - /dev/dri
      - /dev/uinput
      - /dev/uhid
    ports:
      - "47984:47984/tcp"
      - "47989:47989/tcp"
      - "47999:47999/udp"
      - "48010:48010/tcp"
      - "48100:48100/udp"
      - "48200:48200/udp"
    restart: always

config.toml app:

[[profiles.apps]]
    icon_png_path = 'icons/playstation.png'
    title = 'chiaki-ng'

        [profiles.apps.runner]
        base_create_json = '''{
        "HostConfig": {
                "IpcMode": "host",
                "CapAdd": ["SYS_ADMIN", "SYS_NICE", "SYS_PTRACE", "NET_RAW", "MKNOD", "NET_ADMIN"],
                "SecurityOpt": ["seccomp=unconfined", "apparmor=unconfined"],
                "Ulimits": [{"Name":"nofile", "Hard":10240, "Soft":10240}],
                "Privileged": false,
                "DeviceCgroupRules": ["c 13:* rmw", "c 244:* rmw"]
                }
        }'''
        devices = []
        env = [ 'RUN_SWAY=true', 'GOW_REQUIRED_DEVICES=/dev/input/* /dev/dri/* /dev/nvidia*' ]
        image = 'gow/chiaki-ng'
        mounts = [ '/usr/bin/dualsensectl:/usr/bin/dualsensectl', '/home/mason/doc/wolf/wolf/swayconfig:/cfg/sway/config' ]
        name = 'WolfChiaki'
        ports = []
        type = 'docker'

The container I am mainly testing with is custom and can be found in the link below. However, I have also tested with the wolf container itself and dualsensectl. I am naive about the inner workings of wolf though, so I am not sure if that is a good way to test or not.

https://github.com/Masong19hippows/GOW-chiaki

Thanks in advance!

Originally created by @Masong19hippows on GitHub (May 28, 2026). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/414 Hey, So I use a Dualsense controller connected to wolf within a Proxmox VM. Basic controller functions work fine, however some of the features like adaptive triggers and the touchpad don't work. I have tried numerous combinations with forwarding inputs and messing with privileged vs unprivileged containers. I have tested with dualsensectl for the most part. Before I dive any deeper, I want to confirm that these things are supposed to work. I can't find any good documentation to confirm or deny this. I have also attached my configs below in case you see an obvious issue. docker-compose.yml: ```yaml services: wolf: image: ghcr.io/games-on-whales/wolf:stable environment: # Add this line - WOLF_SOCKET_PATH=/var/run/wolf/wolf.sock - WOLF_LOG_LEVEL=DEBUG volumes: - ./wolf:/etc/wolf - /usr/bin/dualsensectl:/usr/bin/dualsensectl - /var/run/docker.sock:/var/run/docker.sock:rw - /dev/:/dev/:rw - /run/udev:/run/udev:rw - /var/run/wolf:/var/run/wolf device_cgroup_rules: - 'c 13:* rmw' devices: - /dev/dri - /dev/uinput - /dev/uhid ports: - "47984:47984/tcp" - "47989:47989/tcp" - "47999:47999/udp" - "48010:48010/tcp" - "48100:48100/udp" - "48200:48200/udp" restart: always ``` config.toml app: ```toml [[profiles.apps]] icon_png_path = 'icons/playstation.png' title = 'chiaki-ng' [profiles.apps.runner] base_create_json = '''{ "HostConfig": { "IpcMode": "host", "CapAdd": ["SYS_ADMIN", "SYS_NICE", "SYS_PTRACE", "NET_RAW", "MKNOD", "NET_ADMIN"], "SecurityOpt": ["seccomp=unconfined", "apparmor=unconfined"], "Ulimits": [{"Name":"nofile", "Hard":10240, "Soft":10240}], "Privileged": false, "DeviceCgroupRules": ["c 13:* rmw", "c 244:* rmw"] } }''' devices = [] env = [ 'RUN_SWAY=true', 'GOW_REQUIRED_DEVICES=/dev/input/* /dev/dri/* /dev/nvidia*' ] image = 'gow/chiaki-ng' mounts = [ '/usr/bin/dualsensectl:/usr/bin/dualsensectl', '/home/mason/doc/wolf/wolf/swayconfig:/cfg/sway/config' ] name = 'WolfChiaki' ports = [] type = 'docker' ``` The container I am mainly testing with is custom and can be found in the link below. However, I have also tested with the wolf container itself and dualsensectl. I am naive about the inner workings of wolf though, so I am not sure if that is a good way to test or not. https://github.com/Masong19hippows/GOW-chiaki Thanks in advance!

bsakaguchi 2026-10-15 12:59:05 +00:00

• closed this issue
• added the
  documentation
  question
  labels

bsakaguchi commented 2026-10-15 12:59:06 +00:00

Author

Owner

Copy link

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

Hi there 👋
Sorry it took me long to reply, but I knew it's going to be a long reply..

I have tried numerous combinations with forwarding inputs and messing with privileged vs unprivileged containers.

That isn't required, and it can actually mess with the setup. If you have any of those changes please revert back to the defaults in the quickstart guide

Before I dive any deeper, I want to confirm that these things are supposed to work

Yep, we've got full support for Gyro, Acceleration, Touchpad, Adaptive triggers, LED and battery status. Obviously this only works with games that fully support that, for example, when using Steam you have to disable steam input and use a game that natively support DualSense for those features to be available.

Troubleshooting

A few things that can help you to figure out what's the issue:

• Wolf need access to /dev/uhid, make sure that you've added the udev rules in your host from here
• When plugging the DualSense device to an app container Wolf should mount /dev/input/eventX (for basic joypad support) and /dev/hidrawX this is the important one, apps/games that support native DualSense would access this instead of the event device.
• Our images bundle a little custom utility sdl2-jstest that you can use from CLI (sdl2-jstest --gamecontroller 0 IIRC) to access all the advanced features of the DualSense device including gyro and acceleration. You can press the microphone button to cycle the different trigger effects.

Hope this helps!

<!-- gh-comment-id:4582327693 --> @ABeltramo commented on GitHub (May 30, 2026): Hi there 👋 Sorry it took me long to reply, but I knew it's going to be a long reply.. > I have tried numerous combinations with forwarding inputs and messing with privileged vs unprivileged containers. That isn't required, and it can actually mess with the setup. If you have any of those changes please revert back to the defaults in the [quickstart guide](https://games-on-whales.github.io/wolf/stable/user/quickstart.html) > Before I dive any deeper, I want to confirm that these things are supposed to work Yep, we've got full support for Gyro, Acceleration, Touchpad, Adaptive triggers, LED and battery status. Obviously this only works with games that fully support that, for example, when using Steam you have to disable steam input and use a game that natively support DualSense for those features to be available. ## Troubleshooting A few things that can help you to figure out what's the issue: - Wolf need access to `/dev/uhid`, make sure that you've added the udev rules in your host from [here](https://games-on-whales.github.io/wolf/stable/user/quickstart.html#_virtual_devices_support) - When plugging the DualSense device to an app container Wolf should mount `/dev/input/eventX` (for basic joypad support) and `/dev/hidrawX` **this is the important one**, apps/games that support native DualSense would access this instead of the event device. - Our images bundle a little custom utility [sdl2-jstest](https://github.com/games-on-whales/sdl-jstest) that you can use from CLI (`sdl2-jstest --gamecontroller 0` IIRC) to access all the advanced features of the DualSense device including gyro and acceleration. You can press the microphone button to cycle the different trigger effects. Hope this helps!

bsakaguchi commented 2026-10-15 12:59:06 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 1, 2026):

I have already added those udev rules, however /dev/hidraw* is created with root:root instead of root:input, and so I am not sure they are being applied correctly. Manually changing it to rooot:input also doesn't fix the issue.

/dev/hidraw1 is mounted in the container with root:root, however none of the advanced features work. Pressing the microphone button does not do anything to the triggers, and it also doesn't turn on the mic led.

I also get this error periodically when using sdl2-jstest "error: failed to read gamecontrollerdb.txt: Invalid RWops". The test program recognizes it as a dualsense controller though.

I don't know if this is relevant or not, but my controller is also on some older firmware from 2023, and do to jailbreak reasons, I do not want to update it. I don't know if this older firmware presents it differently to the input system or not.

<!-- gh-comment-id:4589120671 --> @Masong19hippows commented on GitHub (Jun 1, 2026): I have already added those udev rules, however /dev/hidraw* is created with root:root instead of root:input, and so I am not sure they are being applied correctly. Manually changing it to rooot:input also doesn't fix the issue. /dev/hidraw1 is mounted in the container with root:root, however none of the advanced features work. Pressing the microphone button does not do anything to the triggers, and it also doesn't turn on the mic led. I also get this error periodically when using sdl2-jstest "error: failed to read gamecontrollerdb.txt: Invalid RWops". The test program recognizes it as a dualsense controller though. I don't know if this is relevant or not, but my controller is also on some older firmware from 2023, and do to jailbreak reasons, I do not want to update it. I don't know if this older firmware presents it differently to the input system or not.

bsakaguchi commented 2026-10-15 12:59:06 +00:00

Author

Owner

Copy link

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

The test program recognizes it as a dualsense controller though.

Does gyro and acceleration work?

The only other thing I can think of is if the Moonlight client doesn't advertise the features, which one are you using? Can you try a different one?

<!-- gh-comment-id:4590010912 --> @ABeltramo commented on GitHub (Jun 1, 2026): > The test program recognizes it as a dualsense controller though. Does gyro and acceleration work? The only other thing I can think of is if the Moonlight client doesn't advertise the features, which one are you using? Can you try a different one?

bsakaguchi commented 2026-10-15 12:59:06 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 1, 2026):

It looks like gyro and acceleration works.

I am using the official client, but I understand that its not really maintained well. I just tried the client here, but the controller was recognized as "PS5 controller" instead of dualsense. The gyro and acceleration wasn't even an option when running the program. I also tried moonlight repacked from here with the same results.

Still also got this error when using the program "error: failed to read gamecontrollerdb.txt: Invalid RWops".

Want client did you guys use to test this functionality? Is there a preferred client?

<!-- gh-comment-id:4593957503 --> @Masong19hippows commented on GitHub (Jun 1, 2026): It looks like gyro and acceleration works. I am using the official client, but I understand that its not really maintained well. I just tried the client [here](https://github.com/wjbeckett/artemis/releases), but the controller was recognized as "PS5 controller" instead of dualsense. The gyro and acceleration wasn't even an option when running the program. I also tried moonlight repacked from [here](https://apps.microsoft.com/detail/9nkn9n4f7xt6?hl=en-US&gl=US) with the same results. Still also got this error when using the program "error: failed to read gamecontrollerdb.txt: Invalid RWops". Want client did you guys use to test this functionality? Is there a preferred client?

bsakaguchi commented 2026-10-15 12:59:07 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 1, 2026):

I think I might have found part of the issue. It looks like the exact commands sent to the controller that sdl-test uses for adaptive triggers might be out of date.

I plugged my controller into a pc outside of wolf and tried using the test program, but I got the same results. Upon further looking, it looks like dualsense.h hasn't been updated in a year and the commands used were deprecated as of then. I think something just updated and those commands were fully deprecated. Dualsensectl is working fine with this setup and the adaptive triggers are also working for it. It seems like there is just something wrong with sdl2-jstest itself. I can investigate more tonight and maybe send a PR your way.

<!-- gh-comment-id:4595161704 --> @Masong19hippows commented on GitHub (Jun 1, 2026): I think I might have found part of the issue. It looks like the exact commands sent to the controller that sdl-test uses for adaptive triggers might be out of date. I plugged my controller into a pc outside of wolf and tried using the test program, but I got the same results. Upon further looking, it looks like [dualsense.h](https://github.com/games-on-whales/sdl-jstest/blob/master/src/utils/dualsense.h) hasn't been updated in a year and the commands used were deprecated as of then. I think something just updated and those commands were fully deprecated. Dualsensectl is working fine with this setup and the adaptive triggers are also working for it. It seems like there is just something wrong with sdl2-jstest itself. I can investigate more tonight and maybe send a PR your way.

bsakaguchi commented 2026-10-15 12:59:07 +00:00

Author

Owner

Copy link

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

Or maybe this is tied to your specific old firmware that you mentioned before? You are the first one to report this kind of issues with the DualSense implementation..

<!-- gh-comment-id:4595212134 --> @ABeltramo commented on GitHub (Jun 1, 2026): Or maybe this is tied to your specific old firmware that you mentioned before? You are the first one to report this kind of issues with the DualSense implementation..

bsakaguchi commented 2026-10-15 12:59:07 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 1, 2026):

Forgot to mention it, but I also updated the firmware of the controller to the latest last night - before testing today outside of wolf. Everything should be up-to-date with the latest tests where I mentioned those depricated commands.

Are you able to test this yourself? I can spin up a new VM to make sure its not an environment issue, but I think its a sure sign when dualsensectl works but sdl2-jstest isn't.

<!-- gh-comment-id:4595241074 --> @Masong19hippows commented on GitHub (Jun 1, 2026): Forgot to mention it, but I also updated the firmware of the controller to the latest last night - before testing today outside of wolf. Everything should be up-to-date with the latest tests where I mentioned those depricated commands. Are you able to test this yourself? I can spin up a new VM to make sure its not an environment issue, but I think its a sure sign when dualsensectl works but sdl2-jstest isn't.

bsakaguchi commented 2026-10-15 12:59:07 +00:00

Author

Owner

Copy link

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

How are you actually testing this? Running it in a container or have you built our little tool on your host? Which OS and Linux kernel version are you running?

I'll test it again on my end too, I'm running the latest Arch on my dev machine.

<!-- gh-comment-id:4595529980 --> @ABeltramo commented on GitHub (Jun 1, 2026): How are you actually testing this? Running it in a container or have you built our little tool on your host? Which OS and Linux kernel version are you running? I'll test it again on my end too, I'm running the latest Arch on my dev machine.

bsakaguchi commented 2026-10-15 12:59:07 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 1, 2026):

Sorry, I didn't realize I gave such little info on my setup.

I compiled your tool locally on a ubuntu 24.04 vm using 6.17 generic kernel. This is outside of any container system and just inside of the vm using USB passthrough via proxmox for the controller.

I also locally compiled dualsensectl for testing. Both are ran with sudo, however sdl2-jstest doesn't do anything to the adaptive triggers while dualsensectl does.

Using the trigger cycle thing with sdl2-jstest though, it looks like the controller itself on the 3rd option rumbles when the triggers are pressed, however the adaptive triggers don't function.

<!-- gh-comment-id:4595691729 --> @Masong19hippows commented on GitHub (Jun 1, 2026): Sorry, I didn't realize I gave such little info on my setup. I compiled your tool locally on a ubuntu 24.04 vm using 6.17 generic kernel. This is outside of any container system and just inside of the vm using USB passthrough via proxmox for the controller. I also locally compiled dualsensectl for testing. Both are ran with sudo, however sdl2-jstest doesn't do anything to the adaptive triggers while dualsensectl does. Using the trigger cycle thing with sdl2-jstest though, it looks like the controller itself on the 3rd option rumbles when the triggers are pressed, however the adaptive triggers don't function.

bsakaguchi commented 2026-10-15 12:59:08 +00:00

Author

Owner

Copy link

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

Just tested this on Linux 7.0.7-arch2-1 using sdl2-compat 2.32.68-1 (sdl3 3.4.8-1) with a DualSense directly plugged to the host and sdl2-jstest --gamecontroller 0 correctly picks everything up. Pressing the microphone button cycles thru the different vibration modes including adaptive triggers.

I feel this might be tied to the "old" 24.04 Ubuntu version; if you could test that in a more recent VM it might help to narrow down the issue.

<!-- gh-comment-id:4595865410 --> @ABeltramo commented on GitHub (Jun 1, 2026): Just tested this on Linux `7.0.7-arch2-1` using `sdl2-compat 2.32.68-1` (`sdl3 3.4.8-1`) with a DualSense directly plugged to the host and `sdl2-jstest --gamecontroller 0` correctly picks everything up. Pressing the microphone button cycles thru the different vibration modes including adaptive triggers. I feel this might be tied to the "old" `24.04` Ubuntu version; if you could test that in a more recent VM it might help to narrow down the issue.

bsakaguchi commented 2026-10-15 12:59:08 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 1, 2026):

I can work on getting a ubuntu vm setup with 25.05 later today. I try to stay away from the latest "lts" version because alot of stuff isn't in the newer repos until a couple of years down the line. I also had to backport your docker containers for the same reason (intel arc drivers not available on 25.05), so it would make sense if that was the issue.

Did you run that in a vm, and are you able to update your controller and test again? I want to make sure this isn't a weird firmware thing either.

<!-- gh-comment-id:4595914874 --> @Masong19hippows commented on GitHub (Jun 1, 2026): I can work on getting a ubuntu vm setup with 25.05 later today. I try to stay away from the latest "lts" version because alot of stuff isn't in the newer repos until a couple of years down the line. I also had to backport your docker containers for the same reason (intel arc drivers not available on 25.05), so it would make sense if that was the issue. Did you run that in a vm, and are you able to update your controller and test again? I want to make sure this isn't a weird firmware thing either.

bsakaguchi commented 2026-10-15 12:59:08 +00:00

Author

Owner

Copy link

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

Did you run that in a vm, and are you able to update your controller and test again?

No VM, that is a normal Arch installation on bare metal. I haven't checked the DualSense firmware in a while but I'd be surprised if that's the case; this really smells like a kernel change. I'll checkout dualsensectl though, sounds like that's a great little utility to have in the toolbox.

<!-- gh-comment-id:4595965732 --> @ABeltramo commented on GitHub (Jun 1, 2026): > Did you run that in a vm, and are you able to update your controller and test again? No VM, that is a normal Arch installation on bare metal. I haven't checked the DualSense firmware in a while but I'd be surprised if that's the case; this really smells like a kernel change. I'll checkout dualsensectl though, sounds like that's a great little utility to have in the toolbox.

bsakaguchi commented 2026-10-15 12:59:08 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 1, 2026):

I think you are right with some sort of kernel change. I started to spin up a new vm, and while I did, I also installed the hwe kernel on my 24.04 vm. This changed the kernel from 6.17.0-29 -> 6.17.0-35. This seemed to make it work with root on the host machine. I am not sure if its a kernel difference itself, or maybe some driver that was left out with my original kernel. I use ubuntu server, and I am not sure how kernel drivers work between ubuntu server vs ubuntu. Maybe hwe just added a driver that was missing? Thank you for helping clarify that with me.

However, the original problem still persists, and I think I have a clue on where the issue is. It seems that sdl2-jstest only works with the adaptive triggers if executed with sudo. If I use a non-root user, everything else except for the adaptive triggers, gyro, and acceleration work. If I execute it as non-root, it shows up as "PS5 Controller" instead of "Dualsense wireless controller". This is the exact same behavior that happens when I use my controller through wolf. I think this hints to some underlying permissions issue.

On the host machine, I used chown to change /dev/hidraw1 to root:input instead of root:root that it originally was. This makes sdl2-jstest on the host work as non-root with the adaptive triggers, gyro, and acceleration. I think this means that the udev rules are either incorrect, or not being applied.

Here is the territory that I am not really familiar with though. I don't really know much about the linux input system other than the very basics. I only have 2 files in /etc/udev/rules.d/. Those are "85-wolf-virtual-inputs.rules" with the rules in your guide, and "ubuntu--vg-ubuntu--lv.rules" which contains "SUBSYSTEM=="block", ACTION=="add|change", ENV{DM_NAME}=="ubuntu--vg-ubuntu--lv", SYMLINK+="disk/by-dname/ubuntu--vg-ubuntu--lv". It doesn't look like the recommended rule KERNEL=="hidraw*", ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="input", MODE="0660", ENV{ID_SEAT}="seat9" is being applied.

<!-- gh-comment-id:4596800172 --> @Masong19hippows commented on GitHub (Jun 1, 2026): I think you are right with some sort of kernel change. I started to spin up a new vm, and while I did, I also installed the hwe kernel on my 24.04 vm. This changed the kernel from 6.17.0-29 -> 6.17.0-35. This seemed to make it work with root on the host machine. I am not sure if its a kernel difference itself, or maybe some driver that was left out with my original kernel. I use ubuntu server, and I am not sure how kernel drivers work between ubuntu server vs ubuntu. Maybe hwe just added a driver that was missing? Thank you for helping clarify that with me. However, the original problem still persists, and I think I have a clue on where the issue is. It seems that sdl2-jstest only works with the adaptive triggers if executed with sudo. If I use a non-root user, everything else except for the adaptive triggers, gyro, and acceleration work. If I execute it as non-root, it shows up as "PS5 Controller" instead of "Dualsense wireless controller". This is the exact same behavior that happens when I use my controller through wolf. I think this hints to some underlying permissions issue. On the host machine, I used chown to change /dev/hidraw1 to root:input instead of root:root that it originally was. This makes sdl2-jstest on the host work as non-root with the adaptive triggers, gyro, and acceleration. I think this means that the udev rules are either incorrect, or not being applied. Here is the territory that I am not really familiar with though. I don't really know much about the linux input system other than the very basics. I only have 2 files in /etc/udev/rules.d/. Those are "85-wolf-virtual-inputs.rules" with the rules in your guide, and "ubuntu--vg-ubuntu--lv.rules" which contains `"SUBSYSTEM=="block", ACTION=="add|change", ENV{DM_NAME}=="ubuntu--vg-ubuntu--lv", SYMLINK+="disk/by-dname/ubuntu--vg-ubuntu--lv"`. It doesn't look like the recommended rule `KERNEL=="hidraw*", ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="input", MODE="0660", ENV{ID_SEAT}="seat9"` is being applied.

bsakaguchi commented 2026-10-15 12:59:08 +00:00

Author

Owner

Copy link

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

Ha! Right right, the bit you are missing is that Wolf runs as root in the container by default, so it gets access to /dev/hidrawX.

To access that in your host you need to change the udev rule. On my dev machine it works because I have Steam installed which comes with it's own set of rules which gives me user access. Without hidraw SDL can't access the advanced features of the joypad.

With the new kernel, if everything works with sudo, everything should work under Wolf too. Wolf runs as root and it then mounts and gives access to the right device to the app containers which are running as unprivileged.

<!-- gh-comment-id:4596864602 --> @ABeltramo commented on GitHub (Jun 1, 2026): Ha! Right right, the bit you are missing is that Wolf runs as `root` in the container by default, so it gets access to `/dev/hidrawX`. To access that in your host you need to change the udev rule. On my dev machine it works because I have Steam installed which comes with it's own [set of rules](https://github.com/ValveSoftware/steam-devices/blob/39e7bd00f7a322e5165fd8f416b31d23daf6d385/60-steam-input.rules#L41) which gives me user access. Without hidraw SDL can't access the advanced features of the joypad. With the new kernel, if everything works with sudo, everything should work under Wolf too. Wolf runs as `root` and it then mounts and gives access to the right device to the app containers which are running as unprivileged.

bsakaguchi commented 2026-10-15 12:59:08 +00:00

Author

Owner

Copy link

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

And just to add: the default Wolf rules are moving virtual joypads to be root only on purpose so that they don't overlap with a normal desktop session; hence achieving full isolation.

Hope all that makes sense now 😅

<!-- gh-comment-id:4596900980 --> @ABeltramo commented on GitHub (Jun 1, 2026): And just to add: the default Wolf rules are moving virtual joypads to be root only on purpose so that they don't overlap with a normal desktop session; hence achieving full isolation. Hope all that makes sense now 😅

bsakaguchi commented 2026-10-15 12:59:09 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 1, 2026):

I agree that everything *should work, but it doesn't. I just rebooted and tried again with a couple of moonlight clients and I got the same result. /dev/hidraw1 is mounted in the container with root:root and gryo/acceleration work, but the adaptive triggers don't function using the cycle method.

Were you able to test using a moonlight client instead of going through the host directly?

That does make sense on why its done like that. I'm just confused on why mine is behaving differently.

<!-- gh-comment-id:4596907420 --> @Masong19hippows commented on GitHub (Jun 1, 2026): I agree that everything *should work, but it doesn't. I just rebooted and tried again with a couple of moonlight clients and I got the same result. /dev/hidraw1 is mounted in the container with root:root and gryo/acceleration work, but the adaptive triggers don't function using the cycle method. Were you able to test using a moonlight client instead of going through the host directly? That does make sense on why its done like that. I'm just confused on why mine is behaving differently.

bsakaguchi commented 2026-10-15 12:59:09 +00:00

Author

Owner

Copy link

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

I haven't tested a full streaming session today but I'm pretty sure it's still working.
I'd suggest testing out a newer VM if you can because that kernel change is really suspicious..
Sorry for all the trouble you are going thru; I'm definitely going to summarise all this in a doc page for troubleshooting.

<!-- gh-comment-id:4596934897 --> @ABeltramo commented on GitHub (Jun 1, 2026): I haven't tested a full streaming session today but I'm pretty sure it's still working. I'd suggest testing out a newer VM if you can because that kernel change is really suspicious.. Sorry for all the trouble you are going thru; I'm definitely going to summarise all this in a doc page for troubleshooting.

bsakaguchi commented 2026-10-15 12:59:09 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 2, 2026):

Sorry this took me awhile. I spun up a ubuntu desktop 26.06 LTS vm using kernel 7.0.0-22, installed docker, did the udev rules, rebooted, then used the official moonlight client with my ps5 controller hardwired to my computer.

This had the exact same behavior as outlined above with my 24.04 server vm. Everything works except the adaptive triggers. Can you please try this as well?

<!-- gh-comment-id:4597795214 --> @Masong19hippows commented on GitHub (Jun 2, 2026): Sorry this took me awhile. I spun up a ubuntu desktop 26.06 LTS vm using kernel 7.0.0-22, installed docker, did the udev rules, rebooted, then used the official moonlight client with my ps5 controller hardwired to my computer. This had the exact same behavior as outlined above with my 24.04 server vm. Everything works except the adaptive triggers. Can you please try this as well?

bsakaguchi commented 2026-10-15 12:59:09 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 4, 2026):

I have been looking online, and it seems to be a loose fact that adaptive triggers don't work over wireless because the audio device required isn't there. Even though I have the controller plugged into my machine using moonlight, dualsensectl lists my controller as bluetooth. I think moonlight/wolf exposes the controller in a way where those audio devices arn't present, and it acts just like as if the controller was wirelessly paired. I don't know how true it is though that adaptive triggers don't work wirelessly. I see it sprinkled in random threads, but there are also people saying in those same threads that it works with first party Sony games on PC wirelessly.

I think I also confirmed something related to this is the issue. When I plug in my controller directly to my host machine, a new sound sound device is created in pulseaudio labeled "alsa_card.usb-Sony_Interactive_Entertainment_DualSense_Wireless_Controller-00" and adaptive triggers work. When I use wolf instead, no sound device is created on my host or in the container. Since the adaptive triggers work off of the sound device, I don't think they can work without something being created/used.

Is there a way to have moonlight/wolf expose this sound device?

<!-- gh-comment-id:4623454796 --> @Masong19hippows commented on GitHub (Jun 4, 2026): I have been looking online, and it seems to be a loose fact that adaptive triggers don't work over wireless because the audio device required isn't there. Even though I have the controller plugged into my machine using moonlight, dualsensectl lists my controller as bluetooth. I think moonlight/wolf exposes the controller in a way where those audio devices arn't present, and it acts just like as if the controller was wirelessly paired. I don't know how true it is though that adaptive triggers don't work wirelessly. I see it sprinkled in random threads, but there are also people saying in those same threads that it works with first party Sony games on PC wirelessly. I think I also confirmed something related to this is the issue. When I plug in my controller directly to my host machine, a new sound sound device is created in pulseaudio labeled "alsa_card.usb-Sony_Interactive_Entertainment_DualSense_Wireless_Controller-00" and adaptive triggers work. When I use wolf instead, no sound device is created on my host or in the container. Since the adaptive triggers work off of the sound device, I don't think they can work without something being created/used. Is there a way to have moonlight/wolf expose this sound device?

bsakaguchi commented 2026-10-15 12:59:10 +00:00

Author

Owner

Copy link

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

Sorry for the late reply, I've been busy at work the past couple of days.

The virtual controller that Wolf creates being recognised as a bluetooth device is actually by design. I've been writing a few posts with the low level details of the implementation; here's the last one which cover why the bluetooth implementation is required. As for adaptive triggers not working, that's just not true; see the video in the original PR https://github.com/games-on-whales/wolf/pull/189 which is running our sdl2-jstest over Moonlight in OSX. I've tested the same setup again today and adaptive triggers are working when cycling thru the modalities with the microphone button.

How are you testing this? I feel that you are over relying on dualsensectl, but we need a more rigorous test:

• First off, can you activate the adaptive triggers when running sdl2-jstest on your client?
• Assuming the client can use adaptive triggers, can you confirm if running sdl2-jstest on your remote host (running with root) and a joypad plugged on the client during a streaming session with Wolf actually triggers the adaptive triggers in the client?
• If all that works, which image are you using for Wolf? I'm using the vanilla ghcr.io/games-on-whales/steam:edge to run our utility in a terminal, are you using a custom image?

<!-- gh-comment-id:4625427808 --> @ABeltramo commented on GitHub (Jun 4, 2026): Sorry for the late reply, I've been busy at work the past couple of days. The virtual controller that Wolf creates being recognised as a bluetooth device is actually by design. I've been writing a few posts with the low level details of the implementation; [here's the last one](https://abeltra.me/blog/inputtino-uhid-3/) which cover why the bluetooth implementation is required. As for adaptive triggers not working, that's just not true; see the video in the original PR https://github.com/games-on-whales/wolf/pull/189 which is running our `sdl2-jstest` over Moonlight in OSX. I've tested the same setup again today and adaptive triggers are working when cycling thru the modalities with the microphone button. How are you testing this? I feel that you are over relying on `dualsensectl`, but we need a more rigorous test: - First off, can you activate the adaptive triggers when running `sdl2-jstest` on your client? - Assuming the client can use adaptive triggers, can you confirm if running `sdl2-jstest` on your remote host (running with `root`) and a joypad plugged on the client during a streaming session with Wolf actually triggers the adaptive triggers in the client? - If all that works, which image are you using for Wolf? I'm using the vanilla `ghcr.io/games-on-whales/steam:edge` to run our utility in a terminal, are you using a custom image?

bsakaguchi commented 2026-10-15 12:59:10 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 4, 2026):

Sorry for the late reply, I've been busy at work the past couple of days.

It's all good

The virtual controller that Wolf creates being recognised as a bluetooth device is actually by design. I've been writing a few posts with the low level details of the implementation; here's the last one which cover why the bluetooth implementation is required. As for adaptive triggers not working, that's just not true; see the video in the original PR https://github.com/games-on-whales/wolf/pull/189 which is running our sdl2-jstest over Moonlight in OSX. I've tested the same setup again today and adaptive triggers are working when cycling thru the modalities with the microphone button.

That makes sense. I also just installed the latest sunshine on my Linux server and it's not working for me there as well.

How are you testing this? I feel that you are over relying on dualsensectl, but we need a more rigorous test:

I am using your sdl test command each time. I use docker exec to get a shell into the container where the test program is already installed. Is there a better way to test? The only time I test with dualsensectl is when I am testing on the host machine itself that's running wolf. Even then, I use sdl in combination just because it's easier.

• First off, can you activate the adaptive triggers when running sdl2-jstest on your client?

My client is a windows machine with the latest moonlight installed. I assumed your test program could only be used with Linux. Are you saying the sdl2 test can be used on windows? I used this to test the adaptive trigger functionality on the Windows client, and it works fine.

• Assuming the client can use adaptive triggers, can you confirm if running sdl2-jstest on your remote host (running with root) and a joypad plugged on the client during a streaming session with Wolf actually triggers the adaptive triggers in the client?

I have tried this numerous times with various config options, and I still get the same result. Everything works except for the adaptive triggers. This is the same for normal sunshine running on the host without wolf as well.

• If all that works, which image are you using for Wolf? I'm using the vanilla ghcr.io/games-on-whales/steam:edge to run our utility in a terminal, are you using a custom image?

At first I was using that image + custom patch applied so that I could backport it to Ubuntu 24.04 with Intel arc support. However, I have been using the official image like you have since the first test. I think this issue lies outside of wolf though as it's not working with sunshine either.

I only have a Windows computer with moonlight running as a client right now. It sounds like you are running moonlight on a Linux machine. I have a machine I could repurpose to try that instead. I will let you know the results.

I understand the issue is probably with something on my setup, but I am just super confused on what could be different. I'm starting to think this is something on the client side because everything else is default. With a fresh Ubuntu desktop install, fresh wolf install, etc.

I have only been testing with different moonlight clients on the same windows machine. I can try spinning up a windows VM as well to act as a different client to test with. My windows machine is a work laptop with a bunch of security stuff installed so there's a possibility some driver is not working correctly.

<!-- gh-comment-id:4625528529 --> @Masong19hippows commented on GitHub (Jun 4, 2026): > Sorry for the late reply, I've been busy at work the past couple of days. It's all good > The virtual controller that Wolf creates being recognised as a bluetooth device is actually by design. I've been writing a few posts with the low level details of the implementation; [here's the last one](https://abeltra.me/blog/inputtino-uhid-3/) which cover why the bluetooth implementation is required. As for adaptive triggers not working, that's just not true; see the video in the original PR https://github.com/games-on-whales/wolf/pull/189 which is running our `sdl2-jstest` over Moonlight in OSX. I've tested the same setup again today and adaptive triggers are working when cycling thru the modalities with the microphone button. That makes sense. I also just installed the latest sunshine on my Linux server and it's not working for me there as well. > How are you testing this? I feel that you are over relying on `dualsensectl`, but we need a more rigorous test: I am using your sdl test command each time. I use docker exec to get a shell into the container where the test program is already installed. Is there a better way to test? The only time I test with dualsensectl is when I am testing on the host machine itself that's running wolf. Even then, I use sdl in combination just because it's easier. > - First off, can you activate the adaptive triggers when running `sdl2-jstest` on your client? My client is a windows machine with the latest moonlight installed. I assumed your test program could only be used with Linux. Are you saying the sdl2 test can be used on windows? I used [this](https://ds.daidr.me/) to test the adaptive trigger functionality on the Windows client, and it works fine. > - Assuming the client can use adaptive triggers, can you confirm if running `sdl2-jstest` on your remote host (running with `root`) and a joypad plugged on the client during a streaming session with Wolf actually triggers the adaptive triggers in the client? I have tried this numerous times with various config options, and I still get the same result. Everything works except for the adaptive triggers. This is the same for normal sunshine running on the host without wolf as well. > - If all that works, which image are you using for Wolf? I'm using the vanilla `ghcr.io/games-on-whales/steam:edge` to run our utility in a terminal, are you using a custom image? At first I was using that image + custom patch applied so that I could backport it to Ubuntu 24.04 with Intel arc support. However, I have been using the official image like you have since the first test. I think this issue lies outside of wolf though as it's not working with sunshine either. I only have a Windows computer with moonlight running as a client right now. It sounds like you are running moonlight on a Linux machine. I have a machine I could repurpose to try that instead. I will let you know the results. I understand the issue is probably with something on my setup, but I am just super confused on what could be different. I'm starting to think this is something on the client side because everything else is default. With a fresh Ubuntu desktop install, fresh wolf install, etc. I have only been testing with different moonlight clients on the same windows machine. I can try spinning up a windows VM as well to act as a different client to test with. My windows machine is a work laptop with a bunch of security stuff installed so there's a possibility some driver is not working correctly.

bsakaguchi commented 2026-10-15 12:59:10 +00:00

Author

Owner

Copy link

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

Ok, that gives me a much better picture. The underlying implementation of both Sunshine and Wolf for the virtual DualSense is the same (as you probably have got by now) but it's at least a bit reassuring that it's consistently not working and it's not just something specific to our stack.

Now, I'm not sure about Windows.. I have left that boat years ago, and I'd like to keep it that way for the time being. 😅
I'm not sure about SDL in WSL, I guess you could try, but it wouldn't surprise me if hidraw isn't available in WSL for one reason or another. I have tested the website that you've linked on Linux with a USB wired DS joypad and adaptive triggers work for me, so I guess that test is a good one.

I would guess that there's something wrong with the old kernel, but you've tested Ubuntu 26.06 and that doesn't change anything, right? I'm a bit lost as to what else to try, could it be something with how the VM is setup? Which Moonlight client have you tested and which version? The PR has been merged in the official Moonlight QT roughly a year ago so I would guess you already have the required change bundled but it wouldn't hurt to double-check..

<!-- gh-comment-id:4625650970 --> @ABeltramo commented on GitHub (Jun 4, 2026): Ok, that gives me a much better picture. The underlying implementation of both Sunshine and Wolf for the virtual DualSense is the same (as you probably have got by now) but it's at least a bit reassuring that it's consistently not working and it's not just something specific to our stack. Now, I'm not sure about Windows.. I have left that boat years ago, and I'd like to keep it that way for the time being. 😅 I'm not sure about SDL in WSL, I guess you could try, but it wouldn't surprise me if `hidraw` isn't available in WSL for one reason or another. I have tested the website that you've linked on Linux with a USB wired DS joypad and adaptive triggers work for me, so I guess that test is a good one. I would guess that there's something wrong with the old kernel, but you've tested Ubuntu 26.06 and that doesn't change anything, right? I'm a bit lost as to what else to try, could it be something with how the VM is setup? Which Moonlight client have you tested and which version? The PR has been merged in the official Moonlight QT roughly a year ago so I would guess you already have the required change bundled but it wouldn't hurt to double-check..

bsakaguchi commented 2026-10-15 12:59:10 +00:00

Author

Owner

Copy link

@Masong19hippows commented on GitHub (Jun 5, 2026):

hidraw indeed is not available on wsl. I have tested with 26.06 with wolf as the server on it with the same results.

I just spun up 2 vms to act as clients. One of them was a windows vm and the other is a linux vm. I passed through my controller to each one to test, and I get the exact same behavior. On the linux vm client, I used the sdl2-jstest program and it worked flawlessly. However once moonlight passed the input, everything except for the adaptive triggers worked witht he same test program on the server. This was the same behavior with windows except I was using that website to test instead. I also executed moonlight with root on the linux client.

The vms are setup through proxmox, and the servers are also vms on the same proxmox server. The original windows client is my work laptop though on bare metal. I tried with the latest moonlight from the official website each time (6.1). I

I could try bare metal, but honestly I'm at a point where I'm convinced there is something wrong with my setup, but I am not sure what. Maybe something to do with proxmox? I have heard people using usb-over-ip instead and I investigated those options with success. I think I might just use those until I have more time to look at this. Might open an issue on sunshine when I do. Kinda wondering if its a difference between ubuntu/arch as well. I know ubuntu isn't always good with usb devices

<!-- gh-comment-id:4632708151 --> @Masong19hippows commented on GitHub (Jun 5, 2026): hidraw indeed is not available on wsl. I have tested with 26.06 with wolf as the server on it with the same results. I just spun up 2 vms to act as clients. One of them was a windows vm and the other is a linux vm. I passed through my controller to each one to test, and I get the exact same behavior. On the linux vm client, I used the sdl2-jstest program and it worked flawlessly. However once moonlight passed the input, everything except for the adaptive triggers worked witht he same test program on the server. This was the same behavior with windows except I was using that website to test instead. I also executed moonlight with root on the linux client. The vms are setup through proxmox, and the servers are also vms on the same proxmox server. The original windows client is my work laptop though on bare metal. I tried with the latest moonlight from the official website each time (6.1). I I could try bare metal, but honestly I'm at a point where I'm convinced there is something wrong with my setup, but I am not sure what. Maybe something to do with proxmox? I have heard people using usb-over-ip instead and I investigated those options with success. I think I might just use those until I have more time to look at this. Might open an issue on sunshine when I do. Kinda wondering if its a difference between ubuntu/arch as well. I know ubuntu isn't always good with usb devices

bsakaguchi commented 2026-10-15 12:59:10 +00:00

Author

Owner

Copy link

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

Really odd, I'm afraid I don't have any other idea on how to unlock this..

I'm going to close this because it feels like it's something very specific with your setup, feel free to ping me and link this issue if you try to open up an issue on Sunshine.

<!-- gh-comment-id:4633012367 --> @ABeltramo commented on GitHub (Jun 5, 2026): Really odd, I'm afraid I don't have any other idea on how to unlock this.. I'm going to close this because it feels like it's something very specific with your setup, feel free to ping me and link this issue if you try to open up an issue on Sunshine.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

beta

feat/fedora-base-images

stable

axolotlitehotfix/randomly-generated-client-id

feat/vulkan-image

ci/image-smoke-harness

nv12-producer-pin

fix/nvidia-zero-copy

fix/amd-dma-buf-negotiation

fix/joypad-input-leak

codex/party-mode-split-render

ci-fedora-images

test/gst-wld-block-linear

fix/nvidia-blackwell-zero-copy

feat/embed-wolf-den

fix/fake-udev-write-db

fix/session-runner-user

fedora-dockerfile

feat/comprehensive-display-modes

aimee/quickstart-scripts

JBailes-patch-1

dev-nix

dev-fake-uinput

dev-tracy

fix/gst_vaapi

v2024.07

v2023.06

v2023.02

v2022.11

Labels

Clear labels   

🧠 1 - 🤖 999

  

AMD

  

bug

  

bug

  

cannot reproduce

  

documentation

  

duplicate

  

easy

  

enhancement

  

enhancement

  

enhancement

  

fixed?

  

fixed?

  

good first issue

  

hard

  

help wanted

  

Intel

  

invalid

  

LXC

  

medium

  

moonlight-protocol

  

Multi GPU

  

nixos

  

not a bug

  

nvidia

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

wontfix

No labels

🧠 1 - 🤖 999

AMD

bug

bug

cannot reproduce

documentation

duplicate

easy

enhancement

enhancement

enhancement

fixed?

fixed?

good first issue

hard

help wanted

Intel

invalid

LXC

medium

moonlight-protocol

Multi GPU

nixos

not a bug

nvidia

pull-request

question

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

games-on-whales/wolf#273

No description provided.