Vibration on DualShok/ DualSense

[wanted8x]

Hi, can you Enable Vibration on DS4/DualSense Controller? ViGEmBus driver has become Update.

Your Text: Disabled broken DS4 feedback support again. Can't have semi-nice things. Don't bring it up again until at least the next ViGEmBus driver update...

Thanks for your Time

[Masamune3210]

Vibration has been back for some time now.....

[wanted8x]

No, on last version 3.0.18 it doesnt work, in games. i use 3.0.10. this is only the version how it worked.

Version 3.0.11 and up, has no Vibration

[wanted8x]

Changelog from version 3.0.11; Disabled broken DS4 feedback support again. Can't have semi-nice things. Don't bring it up again until at least the next ViGEmBus driver update.

[Masamune3210]

I am using the latest version and vibration on both my DS4 and my DualSense very much works

[wanted8x]

On Bluetooth?? No, it worked only with USB Cable.

[wanted8x]

The creator wrote to me at the time that he took out from version 3.0.11 and up. He wanted to reinstall it when Vigembus driver gets update

[Kanuan]

I'm not sure why this project has been opened but anyway:

Hi, can you Enable Vibration on DS4/DualSense Controller? ViGEmBus driver has become Update

The latest version of the ViGEmBus has not fixed the real issue that made DS4Windows disable rumble/lightbar passthru in the first place, so nothing has changed for now

---

On Bluetooth?? No, it worked only with USB Cable

It doesn't work when using DS4Windows' Virtual DS4 regardless if it's connected via cable or BT. If you are using DS4W + Virtual DS4 in the profile settings and rumble is working via cable then that means you are NOT actually using DS4W's virtual DS4, the game is probably ignoring DS4Windows alltogether and directly picking the real controller

Edit 1

It doesnt work in the latest versions, post v3.0.11. On v3.0.10 and olders it is activated but because of the issue with the ViGEmBus users can suffer from infinite rumble

[wanted8x]

Version 3.0.10 works great. Same config; with 3.0.11 and up it doesnt worked via BT. in both config is Virtual DS4 on its all same config with earlier version

[wanted8x]

Okay then I'll keep using the old version

[wanted8x]

In profile is Virtual DS4 enable, and it worked via BT in 3.0.10. You can test it.

[Ryochan7]

I believe I re-enabled the vibration routine for the virtual DS4 shortly before the rage quit with version 3.0.18. Been a while so I should double check and make sure that is the case.

Also, I just checked over the current ViGEmBus code and the root problem with DS4 vibration has not been addressed. It still looks like there is no way to retrieve the full output report payload so the features bytes from the report can be checked. That byte is necessary to determine if a payload should be considered a lightbar change, rumble motor change, or possibly both. I reported on the initial problem on the ViGEmBus repo back around February 2021 IIRC; the issue is still open on the ViGEmBus GitHub issue tracker.

On the plus side, it looks like the way notification data is sent to clients has changed so maybe the old notification queue in the ViGEmClient isn't really necessary for the most recent version of ViGEmBus (1.18.367.0). Would still keep it in as ViGEmBus 1.17.333.0 would still need it and it should not affect the behavior in the current release.

[Ryochan7]

Just double checked and I did not remember correctly. DS4 vibration is disabled in the current DS4Windows code. Not sure how I would feel about re-enabling it and then opening up that can of worms again. Many posted issues would follow that potential change and I cannot do anything about it. That's why DS4 feedback support was removed from the app.

[wanted8x]

Hmm Okay thanks for your time. I‘ll keep using the old version (3.0.10)

[vladborovtsov]

A weird thing with vibration. I'm on version 3.0.18, dualsense. After windows reboot - it works both via cable and bluetooth. But once controller gets disconnected - vibration wont work until next reboot. Maybe someone will find this helpful.

[Ryochan7]

Never had that problem with the DualSense. Did you try rumble using something like the Test Rumble buttons or in some game? Using the Test Rumble buttons in the Profile Editor would help show if something is happening within DS4Windows itself or maybe if a ViGEm feedback notification thread has gotten stuck which has happened in the past.

[Ryochan7]

I am pretty sure I am sticking with my decision to keep virtual DS4 rumble disabled going forward. The feature has never worked as intended. Can't even go about trying to fix it. It is rare to have an Open Source project with the Cathedral model but they clearly exist.

The Cathedral and the Bazaar http://www.catb.org/~esr/writings/cathedral-bazaar/

[coolllman]

Ds4 mode vibration work good on 3.0.10, with no any problem, why not let users choose? Leave it off by default and add a warning about possible problems.

[Masamune3210]

Because people either cant read or wont put the effort in, either way the outcome is the same. People ignore the warning, get annoyed that it isn't working, report a issue and take up time, or somewhat worse, go around trashing the program for it not working after it said it might not work

[Ryochan7]

Ds4 mode vibration work good on 3.0.10, with no any problem, why not let users choose? Leave it off by default and add a warning about possible problems.

Heard this several times before and I am pretty sure I did that in DS4Windows before; even tagged the change with "Disabled broken DS4 feedback support again" in the Changelog. It might have worked well in one game but it won't work correctly in others; in my case, one workaround can work in Streets of Rage 4 but would fail in the Witcher 3. Not my bug, I have no means to fix it, and the newest ViGEmBus driver did not address the problem.

If you really want the issue fixed then you can talk to nefarius. I cannot submit a PR and expect it to get merged.

[nefarius]

Not my bug, I have no means to fix it, and the newest ViGEmBus driver did not address the problem.

Is fixed 👍

[Yohoki]

Would like to clarify, before we get people saying "Nefarius said it's fixed! Why no working?"

The ViGEmBus driver is fixed. DS4Windows needs to be updated to support the new features. Please be patient. :)

Also, thanks for the update, Nefarius!

[nefarius]

Would like to clarify, before we get people saying "Nefarius said it's fixed! Why no working?"

The ViGEmBus driver is fixed. DS4Windows needs to be updated to support the new features. Please be patient. :)

Yes, that is a very important distinction! 😉 Plus the latest driver needs to circulate and be pushed to affected users etc. etc. etc.

In essence: patience.

[Ryochan7]

Plenty of prerequisites going into possibly making the change. Need to go up the whole client SDK stack and add the custom changes that DS4Windows uses. Performance tests and probably other tasks before possibly adding the new feedback hook for applicable ViGEmBus versions; already know that later Fody versions used in ViGEm.NET kill performance significantly. Going to take a while especially since I haven't spent much time on this project lately. Been spending many hours biking every day.

Super Bummerman 2 (retsupurae) https://youtu.be/OC1SzVR5zeo?t=320

[nefarius]

Been spending many hours biking every day.

Sounds like a healthy alternative to coding.

already know that later Fody versions used in ViGEm.NET kill performance significantly.

If you'd tell me more about that I could improve upon it. Never gave Fody another look since its only involvement is loading the embedded native DLLs in memory, nothing more.

[Ryochan7]

Getting around to working on those prerequisites. Rebased the custom changes on top of the current upstream ViGEmClient and ViGEm.NET code. Ended up finding a way to get Fody to behave better with a tweak to the ViGEm.NET csproj file; stripping the IncludeAssets tag was a massive improvement and it is not needed for building or loading the built assembly. The library is more snappy than ever. Didn't need to do anything extra for ViGEmClient after the rebase.

https://github.com/Ryochan7/ViGEm.NET/tree/ryochan_v1.19-experimental https://github.com/Ryochan7/ViGEmClient/tree/notification_queue_v1.19

Other than that, previously, I had experimented with the current ViGEmBus code to try to find out why output performance took a dive with 1.18. Looks like it was nothing wrong with the actual source code. Just unoptimized default Visual Studio build settings popping up again. Besides changing build settings for ViGEmBus, it would seem like build settings have to be changed for the local DMF copy used by the ViGEmBus project although I have not reverted DMF configuration back to ensure that is truly the case. With just compiler setting tweaks, the driver is faster than ever.

Now that the library issues are mostly resolved, getting around to playing with the new API can begin.

[nefarius]

Other than that, previously, I had experimented with the current ViGEmBus code to try to find out why output performance took a dive with 1.18. Looks like it was nothing wrong with the actual source code. Just unoptimized default Visual Studio build settings popping up again. Besides changing build settings for ViGEmBus, it would seem like build settings have to be changed for the local DMF copy used by the ViGEmBus project although I have not reverted DMF configuration back to ensure that is truly the case. With just compiler setting tweaks, the driver is faster than ever.

What does that actually mean in numbers? How do you benchmark? I've contacted the DMF authors about default build settings and they recommended to stay on the defaults which I am inclined to believe because a) they have the telemetry data and b) my own benchmarks confirm that there is no human-noticeable difference whatsoever:

The screenshot shows the time it takes for each packet submission to be processed.

[nefarius]

Ended up finding a way to get Fody to behave better with a tweak to the ViGEm.NET csproj file; stripping the IncludeAssets tag was a massive improvement and it is not needed for building or loading the built assembly.

What performance improved? Assembly load delay? Interop speed?

[Ryochan7]

Update. Got an initial draft going that seems like it works like a direct connection. Both Witcher 3 and Streets of Rage 4 are working and displaying the proper lightbar color and vibrating. I don't know of any PC game that utilizes the DS4 lightbar flash feature but got that check implemented as well. Probably going to have to change how the feedback routine is performed for all DS4OutDevice classes to abstract the details more; the base class expects the use of DualShock4FeedbackReceivedEventHandler and that will no longer be valid with the new API.

Example patch (relies on other changes outside of the ControlService class): https://gist.github.com/Ryochan7/7329c4355e38ccebe391a844717998ba

Also, got around to testing my hypothesis for the current ViGEmBus code. I reverted DMF to use the default Release build settings and rebuilt both DMF and ViGEmBus. Performance took a dive again even with ViGEmBus still using more optimized build settings. The build settings for DMF have to be changed so ViGEmBus can perform like it used to.

[Yohoki]

Sounds like a great bit of progress. Thanks Nefarius and Ryochan for that work! Looking forward to seeing the changes. It's a feature we've been waiting to see for a while.

[Ryochan7]

Here is a video attempting to show what I am experiencing regarding later versions of Fody and the use of the IncludeAssets tag

DS4Windows Fody Regression Demo: https://www.youtube.com/watch?v=P28pEUh51O0

Maybe I will get around to showing off the differences I have been experiencing with the current ViGEmBus build. For now, here is a diff of the build setting changes made to the relevant projects in DMF; Visual Studio 2019 decided to make some other random changes as well.

https://gist.github.com/Ryochan7/afe6e72ea7c0b8ecc24b8f8aa5e1e0bd

Currently using the optimized version of the 1.19 ViGEmBus driver for testing as my computer runs super slow with the vanilla pre-release driver and 1.18 even without a mapper running. Can feel the difference just trying to navigate files in Windows Explorer.

[Ryochan7]

Made a short video trying to demonstrate some performance differences when using the current pre-release 1.19 driver and the current experimental build. Besides just showing the impact of the driver in Windows itself, I used Streets of Rage 4 to demonstrate what behavior I am experiencing on my machine. Added timestamps for relevant sections

DS4Windows ViGEmBus 1.19 experimental build changes: https://www.youtube.com/watch?v=tnlOCDD7GkE

[nefarius]

Thanks for the videos, here's a driver build with everything turned up to eleven, happy testing.

Fody is technically not necessary, it's more of a convenience feature. We can ship around it by also including the client DLLs in the setup and placing them in the system directories where DllImport can pick them up without Costura.

Cheers

[nefarius]

Currently using the optimized version of the 1.19 ViGEmBus driver for testing as my computer runs super slow with the vanilla pre-release driver and 1.18 even without a mapper running. Can feel the difference just trying to navigate files in Windows Explorer.

This I can't really explain; the driver does quite literally "nothing" when just installed and nothing talks to it 🤔 but DMF is big, maybe something hiding in there, although should not be. Computers are stupid.

[Ryochan7]

Draft 2. Not exactly what I thought I would do but it works. Now DS4OutDeviceExt has more control over the process and it can work with multiple output controllers. The first draft only worked for a single output controller.

https://gist.github.com/Ryochan7/7329c4355e38ccebe391a844717998ba

Also found an oversight in the device unplug code with regards to not unhooking force feedback handlers. Probably not a real issue by the time an output device is disposed but probably should be unhooking prior anyway.

[nefarius]

Uh oh, seems like we should do yet another build, user on my Discord noticed that the recent AppVeyor builds use the Windows 11 SDK with VS 2019 which produces regressions left and right, will rebuild with the SDK version clamped down.

[nefarius]

Now it makes more sense why we see performance differences and other weird stuff; the AppVeyor builds are built against the wrong WDK/SDK version due to a build image upgrade, so I'm currently on a mission to clamp down the correct build settings and prepare new binaries sigh

[Ryochan7]

Got a branch with the second draft code in place. Also got the new ViGEm.NET libraries included as those are needed to access the new API calls from the pre-release 1.19 driver. Still need to do some more testing and check out the updated pre-release 1.19 driver and compare it to version 1.17.333.0.

https://github.com/Ryochan7/DS4Windows/tree/awaitoutputbuffer_test

[Ryochan7]

As for my previous concern with feedback handler removal at the OutputSlotManager, it is not a problem in the old code as the Disconnect call actually takes care of removing the feedback handlers already before the virtual controller is disconnected from ViGEmBus. The extra call now is a bit redundant but I think I am going to keep it in place.

[Kanuan]

Because the newer version of ViGEmBus is required to fix the DS4 OutRep issue, how will you handle older ViGEmBus versions?

Asking this because if you go to the "DS4Windows will only support ViGEmBus v1.9 going forward and everyone must update", it would be possible to re-introduce acquiring which XInput slot the controller is connected to when doing X360 emulation, since IIRC someone attempting make a PR for this in the past which was rejected because you had to also support vigembus v1.6 in which this feature was broken.

[Ryochan7]

I don't remember that request. Guess I better search for it and see if it would be more feasible now.

As for this issue, the ViGEmBus version number is passed to the DS4OutDeviceFactory class which will do a simple version check before attempting to use extra features. The ControlService class will only add a handler for the published event if a flag (canUseAwaitOutputBuffer) is set by the device instance.

https://github.com/Ryochan7/DS4Windows/blob/awaitoutputbuffer_test/DS4Windows/DS4Control/DS4OutDevices/DS4OutDeviceFactory.cs#L17

As it is, ViGEmBus 1.16.116 should still be usable IIRC but I would recommend ViGEmBus 1.17.333.0 for the minimum version. The only reason to use 1.16 now is if you are running Windows 8.1 or earlier. ViGEmBus 1.16.116 is not a tested target anymore as Microsoft will officially EOL Windows 8.1 this coming January. Microsoft is going to force people to update eventually.

[nefarius]

@Ryochan7 new release published for testing, includes adjusted compiler settings for both DMF and the main project plus made sure to build against the correct WDK/SDK version (10.0.19041.0). Happy testing.

[Ryochan7]

Installed and performed a small XInputChecker test with ViGEmBus 1.21.442 pre-release. Overall it seems like the major issues I had with later versions of ViGEmBus are gone. Need to perform more exhaustive tests and play some games. Although, so far performance seems much better now and it does outperform ViGEmBus 1.17.333.0 on my machine.

At this rate, the awaitoutputbuffer_test branch is likely done as it does what I want and it works in both Witcher 3 and Streets of Rage 4. Just need to make sure the internal feedback thread properly quits in all situations. Have not run into problems with recent tests since switching to using the timeout version of AwaitRawOutputReport.

At some point I need to get around to testing later versions of HidHide. Also, might want to try to offer some form of driver version checker in future DS4Windows releases.

[Kanuan]

I've also made some quick tests with the awaitoutputbuffer_test branch and the infinite rumble issues were solved in the Hades game.

I did have a strange behavior in which the lightbar would be turned off if I went from Steam/Whatever App or game I was playing back to the desktop, a behavior that didn't happen if using the real DS4v2 under normal conditions, but this could be simply because some random app is picking only ViGEm's Wired DS4v1 (making the lightbar turn off) and not a BT DS4v2. Will do more testing to compare the behavior between using DS4Windows' Virtual DS4 in full pasthru versus using a real DS4v1 via USB

[Yohoki]

Seems like the hop to the new ViGEmBus version is in a stable way and ready for testing! I'll make a build here tonight and see if I can help test a few games. I've only got v1/v2 DS4 controllers, but I'll test both wired and wireless on a few of the games I have.

Quick quide: 🟢 = Working Feature 🟠 = Untested Feature 🟡 = More Info Provided 🔴 = Not Supported/Working Feature ⚠️ = Important information

Detroit: Become Human - 🟢**Lightbar Working**, 🟢**Rumble Working**, 🟠 _Gyro Untested_

- 🟢 ~~Lightbar issues reported. Lightbar should change color depending on character.~~ (**Tested. Working**) - 🟠 Also uses Gyro, but I don't remember that on PC... I mainly played it on PS4 though. So I don't actually know if pc has gyro.

Assassin's Creed [Various] - 🟠 _Lightbar Untested_, 🟢**Rumble Working.**

- 🟢 ~~AC Titles use Rumble.~~ (**Tested. Working**)[Tested on Odyssey and Syndicate] - 🟠 AC:Valhalla uses Lightbar, But I don't have it on PC.

RetroArch - 🟠 _Untested_

- 🟠 Rumble not working.

Dolphin Emulator (🔴 _Rumble Not Supported_, 🟡 _Gyro Somewhat Working_.)

- 🔴 ~~Rumble Not Working~~ (**Tested.** _Not Supported._ Only works in XBox Mode. DS4 not supported by emulator, not a DS4W Issue.) - 🟡 ~~Gyro Not Working~~ (**Tested. Works** _using UDP Server_. DS4 Gyro not supported **by emulator**. UDP can be used instead.)

Witcher 3 (🟢**Lightbar Working**, 🟢**Rumble Working**.)

- 🟢 ~~Rumble issues reported~~ (**Tested. Working.**) - 🟢 ~~Should support lightbar updates~~ (**Tested. Working.**)

Biped (🟡 _Lightbar Somewhat Working_. 🟡 _Rumble Somewhat Working_. ⚠️ Requires Custom EXE name.)

- 🟢 ~~Inf Rumble issue~~ (**Tested. Fixed.**) - 🟡 ~~Rumble works fine in XBox Mode. But no Rumble in DS4 mode. Game still shows DS4 prompts, so **_I may have modded the game, causing issues_**~~. (**Tested. Working** _when using custom EXE name._) - 🟡 ~~Rumble _IS_ working with **D4W turned off**, and a _Wired_ controller connection.~~ (**Tested. Working** _when using custom EXE name._) - 🟡 ~~Lightbar should turn white~~ (**Tested. Working** _when using custom EXE name._) - ⚠️ **Game Detects DS4Windows**. Use a custom EXE name or play with "Turn DS4Windows off temporarily" option set in auto-profile.

Rocket League (🔴 _Rumble Not Supported_.)

- 🔴 ~~Rumble does not work~~ (**Tested.** _Not Supported_ in DS4 mode. Use XBox Emulation. DS4 controller rumble not supported by **game's developers**. Not a DS4W Issue.)

Shadow of the Tomb Raider (🟢 **Rumble Working**.)

- 🟢 ~~Rumble does not work~~ (**Tested. Working.**)

Disney Dreamlight Valley (🟢 **Lightbar Working**, 🔴 _Rumble Not Supported_.)

- 🟢 Lightbar turns ⚪White in game. (**Tested. Working.**) - 🔴 Rumble doesn't work (**Tested.** _Not Supported_ by **game developers**. Not a D4W issue)

Edit: Changed the way the list looks. A little bit cleaner now and easier to see what works and doesn't work, without having all the details in your face. Yes, the arrow HAS to be a line above the text to get the formatting.... blame github.

[Kanuan]

@Yohoki The new branch should have no effect in Sekiro: Shadows die twice since (if I'm not mistaken) the changes affect only the virtual DS4 usage and Sekiro requires virtual Xbox 360. Unless you were using DS4W's Virtual DS4 into Steam's controller support so Steam emulated a Xbox 360 to the game... but then you are asking for problems

In my tests everything worked perfectly fine when using DS4W's virtual Xbox 360. 95% of the people having problem with the controller not being detected were using a pirated version or trying to use Virtual DS4, or... Oh my god, it's a From Software game...

Most games from the FromSoftware developers require: 1) a XInput device to be used and 2) This XInput device must be the very first controller in Windows' controller list, otherwise the controller won't work

[Yohoki]

@Kanuan Ya, I'm specifically looking for games that I remember having issues, or were reported having issues. Rumble's been a big thorn in the program for a while, might as well make sure it's done right or there's just going to be a bunch of "halp is borked" issues popping up again. But, I won't end up testing Sekiro now, anyway. It seems I have deleted it to clear up space...... what in the world was past me thinking???

I did get the test build running and vigem installed, but it looks like I need to restart my computer to actually get DS4 support working again, which I absolutely hate doing.... so I'll start testing in about 3 years when windows is done installing it's forced updates. XD

Edit: Windows has finished it's gauntlet of bloatware additions and testing resumes. So far, it's looking good. D:BH is running well with lightbar and rumble passthru activated on a v2. Updated my original post with testing info.

Only issue I'm running into is WHY DID YOU PUT A LIGHT TO SHINE RIGHT IN THE PLAYER'S EYE???? .... But that's a poor design choice by Sony. Further tests will be performed with the lights on, not in a dark room with no windows. :)

[Yohoki]

Aside from a modded game, and Dolphin not supporting it, I've run into no problems so far with Rumble, Lightbar or Gyro on any of the games I've tested. I added some color codes to my above list to make it easy to see what's 🟢Working, 🔴Not Working, or has other 🟡Information.

Great work @Ryochan7 and @nefarius.

[Ryochan7]

Couple of items to bring up. Related to the compatibility table, many PC games that claim DS4 input support open the controller as a DirectInput device rather than a raw HID device. In a majority of cases, that will mean no form of rumble support will exist; I think Rocket League opens the DS4 in DirectInput mode but it has been a while since I tested it. The DirectInput API has force feedback support and even Gamepad Tester can fire force feedback events for the DS4 when connected in DirectInput mode IIRC.

Also, found that old pull request regarding XInput slots. Looks like it was just a tweak to allow pulling the assigned XInput slot number from the command line. The reason for discarding the request was due to the feature being unreliable in ViGEmBus 1.16.112.0 and that was the minimum support version of the driver. That restraint technically still exists and I would not have a real use for said feature myself. Might try to implement something just to see if it would be worthwhile in the end.

https://github.com/Ryochan7/DS4Windows/pull/2070

[Kanuan]

@Ryochan7 I've created a discussion regarding the Xinput slots since it's unrelated to the current issue. #2567

---

One thing that has come to my knowledge when testing the new branch : Windows' DWM / Windows.Gaming.Input.dll send a Output Report to detected DS4v1 controllers (BT or USB) to... turn off the lightbar. Because of Windows logic. So if anyone is testing and is wondering why the lightbar keeps turning off when switching apps/clicking on the taskbar, that's why. More info here: https://github.com/libretro/retroarch-joypad-autoconfig/issues/852#issuecomment-1220880439

One side-effect of this is that it makes basically impossible to use a DS4v1 via BT in "normal mode" (without DS4Windows I mean). Once the DS4v1 receives the output report it will switch to Extended Mode and then some applications won't be able to "read" the controller anymore. Using DS4Windows this behavior is mitigated since the virtual DS4 is USB and thus is unaffected besides the lightbar being turned off

[Yohoki]

Couple of items to bring up. Related to the compatibility table, many PC games that claim DS4 input support open the controller as a DirectInput device rather than a raw HID device. In a majority of cases, that will mean no form of rumble support will exist; I think Rocket League opens the DS4 in DirectInput mode but it has been a while since I tested it. The DirectInput API has force feedback support and even Gamepad Tester can fire force feedback events for the DS4 when connected in DirectInput mode IIRC.

Looks like RL is free on epic, so I went ahead and checked that one for you as well. No changes there. Rumble still disabled, unfortunately. Also tried with D4W turned off and there's no rumble even with the game directly using the physical controller. So, that's not really a D4W or driver issue.... It's just straight up not supported by the game on PC. Don't think there's anything that can be fixed by you guys. Adding to my list as tested.

That did highlight another thing that I'll bring up in a separate topic, though. Scratch that..... this is a feature small enough that I might be able to implement on my own. I'll give it a shot first. :D