Vibration on DualShok/ DualSense #2439
Comments
|
Vibration has been back for some time now..... |
|
No, on last version 3.0.18 it doesnt work, in games. Version 3.0.11 and up, has no Vibration |
|
Changelog from version 3.0.11; |
|
I am using the latest version and vibration on both my DS4 and my DualSense very much works |
|
On Bluetooth?? No, it worked only with USB Cable. |
|
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 |
|
I'm not sure why this project has been opened but anyway:
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
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 1It 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 |
|
Version 3.0.10 works great. |
|
Okay then I'll keep using the old version |
|
In profile is Virtual DS4 enable, and it worked via BT in 3.0.10. |
|
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. |
|
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. |
|
Hmm Okay thanks for your time. |
|
A weird thing with vibration. I'm on version 3.0.18, dualsense. |
|
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. |
|
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 |
|
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. |
|
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 |
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. |
Is fixed 👍 |
|
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! |
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. |
|
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) |
Sounds like a healthy alternative to coding.
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. |
|
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 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. |
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. |
What performance improved? Assembly load delay? Interop speed? |
|
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): 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. |
|
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. |
|
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. |
|
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. |
|
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. 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. |
|
@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. |
|
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. |
|
I've also made some quick tests with the 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 |
|
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:
|
|
@Yohoki The new branch should have no effect in 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 |
|
@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: 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. :) |
|
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. |
|
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. |
|
@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: libretro/retroarch-joypad-autoconfig#852 (comment) 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 |
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.
|
|
Noticed the first game that something is odd about. Biped. Updated my game list again.
Edit: |
|
It has been a few days but I figured I should update this. The test code has been merged into the master branch. Also, RIP Mrs. Yohoki v1 DS4 |
|
Aside from Biped, it's been working really well in any game I've tried. Haven't noticed any inf rumble popping back up anywhere. Lightbar seem to be supported in any game that already sends lightbar updates without d4w active. Haven't noticed any major input lag. Glad to see it making it into the main. I wouldn't know where to begin debugging on Biped to see what's going on there, though. It's the only game I've tried that disables rumble when D4W is used, but enables it when D4W is turned off. All the other games are behaving identical whether it's virtual or HW DS4. .
It will be missed. T.T Wifey's Pink V1 |
|
Ah. Yep. That did it. Seems this game detects DS4Windows and disables rumble, even though it still detects the controller and allows you to play with it. Custom EXE name fixes it. You can tell it's working because the lightbar turns white in-game (didn't know that was a thing) and rumble starts working again. What an odd thing, to check for DS4Windows, but not actually ban it. Either way, that fixes that game's issues. Adding info to list. |
This is usually associated with using SDL2. Steam, Yuzu, CEMU, Dolphin I think in the latest versions, and some games all use SDL2 for controller support, and SDL2 itself will ignore DS4/DualSense controllers if it detects DS4Windows is running |
|
But those will usually ignore the controller completely right? Biped was only disabling rumble, but letting the inputs through. And even then, the x360 worked fine, not disabling anything if d4w was running. That's why I thought it was odd... It was ONLY rumble that was affected. Not completely disabling controllers. Either way, it seems to be fine now with custom exe names. |
@Ryochan7 Just one comment, I think you've merged the master branch into the AwaitOutputBuffer_test and not the contrary |
|
Can we at least have a toggle button for this somewhere in options like: |
|
Nvm, just realized that with the latest release version of ViGEmBus driver everything works as expected on the latest version of DS4Windows. I just didn't know that we ever need to update ViGEmBus driver manually (I'm always using DS4Updater to upgrade DS4Windows). |
|
@spookyrecharge there is |
|
ViGEmBus ships with an auto updater now so no need. |
|
Hey, can you add audio support for the Dualsense while connected via bluetooth? That would be extremely cool! |
Kindly refrain from hijacking closed threads with unrelated topics, thanks. |
Sorry, I was viewing this thread from the mobile app and didnt know any other way to comment. The app is not very helpful with this. |
|
Just in case, if you are still struggling with activating vibration on ds controller. |
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
The text was updated successfully, but these errors were encountered: