Persistent Vibrate/rumble #1730

Pylon69 · 2021-01-04T01:37:36Z

Second time in 1 month that it's happened.
The controller doesn't stop vibrating and I have to "reboot" the program/stop/start button.
I fear you may have introduced a bug an update or two ago cause I remember updating recently.

Good luck champ

Lunahria · 2021-01-04T08:16:42Z

Which controller are you using and which game did you play?

mika-n · 2021-01-04T09:24:23Z

Make sure you have installed the latest ViGem driver 1.17.333 version. DS4Windows app updater doesn't update ViGem driver automatically. This latest version has various fixes and tweaks related vibration functionality.
https://github.com/ViGEm/ViGEmBus/releases

And what do you see in DS4Windows logfile? It should show the app version and ViGem driver version tags.

Reboot70 · 2021-01-04T15:49:03Z

I'm having the same kind of issue sadly. Light rumble retains after the game or app doesn't send any rumble commands. It happens with the latest release (2.2.1), as well as whichever version of ViGEmBus (1.17.333, 1.16.116), as well as the issue persisting on both Bluetooth and USB with a Dualshock 4 v2. Games I tried this on are Spyro Trilogy and the Dolphin Emulator, but I'm sure this happens on any game. The log files don't indicate any kind of error.
Here is what my log file says:

2021-01-04 16:40:48.2496|INFO|DS4Windows version 2.2.1
2021-01-04 16:40:48.2496|INFO|DS4Windows exe file: DS4Windows.exe
2021-01-04 16:40:48.2496|INFO|DS4Windows Assembly Architecture: x64
2021-01-04 16:40:48.2496|INFO|OS Version: Microsoft Windows NT 10.0.19041.0
2021-01-04 16:40:48.2496|INFO|OS Product Name: Windows 10 Pro
2021-01-04 16:40:48.2496|INFO|OS Release ID: 2004
2021-01-04 16:40:48.2496|INFO|System Architecture: x64
2021-01-04 16:40:48.2496|INFO|Logger created
2021-01-04 16:40:49.1224|INFO|Running as User
2021-01-04 16:40:50.1373|INFO|Starting...
2021-01-04 16:40:50.1373|INFO|Connection to ViGEmBus 1.17.333.0 established
2021-01-04 16:40:50.1373|INFO|Searching for controllers...
2021-01-04 16:40:50.1373|INFO|Using Exclusive Mode
2021-01-04 16:40:51.9599|INFO|Found Controller: 40:1B:5F:C9:CB:58 (USB) (DS4 v.2)
2021-01-04 16:40:52.0500|INFO|Plugging in virtual X360 Controller
2021-01-04 16:40:52.0500|INFO|Associate X360 Controller for input DS4 #1
2021-01-04 16:40:52.0780|INFO|Controller 1 is using Profile "Default". Battery level is 45%

Please let me know if you'd like me to do anything to help debug.

Pylon69 · 2021-01-04T16:30:07Z

Well this friend of ours has walked the mile. If You want my data I'll do what I can. Nontheless this rumble issue was only introduced I. The last patch before this one. It should be an easy fix but it probably won't be. Lol. Bless your souls

…

On Mon, 4 Jan 2021, 17:49 Reboot70, ***@***.***> wrote: I'm having the same kind of issue sadly. Light rumble retains after the game or app doesn't send any rumble commands. It happens with the latest release (2.2.1), as well as whichever version of ViGEmBus (1.17.333, 1.16.116), as well as the issue persisting on both Bluetooth and USB with a Dualshock 4 v2. The log files don't indicate any kind of error. Here is what my log file says: 2021-01-04 16:40:48.2496|INFO|DS4Windows version 2.2.1 2021-01-04 16:40:48.2496|INFO|DS4Windows exe file: DS4Windows.exe 2021-01-04 16:40:48.2496|INFO|DS4Windows Assembly Architecture: x64 2021-01-04 16:40:48.2496|INFO|OS Version: Microsoft Windows NT 10.0.19041.0 2021-01-04 16:40:48.2496|INFO|OS Product Name: Windows 10 Pro 2021-01-04 16:40:48.2496|INFO|OS Release ID: 2004 2021-01-04 16:40:48.2496|INFO|System Architecture: x64 2021-01-04 16:40:48.2496|INFO|Logger created 2021-01-04 16:40:49.1224|INFO|Running as User 2021-01-04 16:40:50.1373|INFO|Starting... 2021-01-04 16:40:50.1373|INFO|Connection to ViGEmBus 1.17.333.0 established 2021-01-04 16:40:50.1373|INFO|Searching for controllers... 2021-01-04 16:40:50.1373|INFO|Using Exclusive Mode 2021-01-04 16:40:51.9599|INFO|Found Controller: 40:1B:5F:C9:CB:58 (USB) (DS4 v.2) 2021-01-04 16:40:52.0500|INFO|Plugging in virtual X360 Controller 2021-01-04 16:40:52.0500|INFO|Associate X360 Controller for input DS4 #1 <#1> 2021-01-04 16:40:52.0780|INFO|Controller 1 is using Profile "Default". Battery level is 45% Please let me know if you'd like to do anything to help debug. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1730 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL4RQBMX7EQM4PYSNEDWJHDSYHPP5ANCNFSM4VSLBIUQ> .

w1lddog2 · 2021-01-04T16:45:01Z

I have the same problem. Sames as the OP, since the last patch.

Pylon69 · 2021-01-04T22:49:45Z

I updated my vigem driver and no difference. I first noticed it whilst playing shadow of the tomb raider.
But last night I was playing Naruto ultimate ninja storm 4. which I've played for centuries and almost every battle the vibration bug would occur(this was never ever an issue before).
Fortunately the game is rumble intensive during battle so the vibrations during battle would undo the remote acting up. Only problem is several times after a battle is done, the controller continued to vibrate until the next battles "battle begins" clash.
I'll repeat, it's only happened once so far with shadow of the tomb raider. Which I'm playing but Naruto ultimate ninja storm 4 is suffering gravely. Of which it never before.
Everything is up-to-date which is probably my crime

Ryusennin · 2021-01-04T23:04:37Z

I haven't experienced locked vibration in a long time.

Try to activate the auto stop rumble option in "Profiles > Controls > Other" and see if it makes a difference. By default it's set at 0 seconds (which means auto stop is disabled).

Pylon69 · 2021-01-04T23:45:16Z

I haven't experienced locked vibration in a long time.

Try to activate the auto stop rumble option in "Profiles > Controls > Other" and see if it makes a difference. By default it's set at 0 seconds (which means auto stop is disabled).

Thanks for the workaround. I'll try it out next time I play

RageSoul · 2021-01-05T15:56:04Z

I haven't experienced locked vibration in a long time.

Try to activate the auto stop rumble option in "Profiles > Controls > Other" and see if it makes a difference. By default it's set at 0 seconds (which means auto stop is disabled).

Did not help.

mika-n · 2021-01-05T16:25:42Z

Hmm..... If the auto-stop rumble option doesn't help then it must mean that
Option 1: the game sends some rumble commands because the "Rumble auto-stop timer" won't do its job as long a game sends rumble commands (ie if for some reason the rumble-zero command sent by a game is lost in hyperspace then auto-stop timer would eventually stop the rumble motor. That is the idea behind the auto-stop timer, but if the game keeps sending rumble commands then auto-stop timer thinks there is no need to stop anything).

Option 2: For some reason the "rumble-zero" command sent by DS4Windows app to the physical DS4 gamepad never make its way to the gamepad. Well, probably never happen in USB connections but in theory BT connections may have some "radio wave" related issues.

Is the issue the same both over USB and BT?

RageSoul · 2021-01-05T17:16:28Z

Hmm..... If the auto-stop rumble option doesn't help then it must mean that
Option 1: the game sends some rumble commands because the "Rumble auto-stop timer" won't do its job as long a game sends rumble commands (ie if for some reason the rumble-zero command sent by a game is lost in hyperspace then auto-stop timer would eventually stop the rumble motor. That is the idea behind the auto-stop timer, but if the game keeps sending rumble commands then auto-stop timer thinks there is no need to stop anything).

Option 2: For some reason the "rumble-zero" command sent by DS4Windows app to the physical DS4 gamepad never make its way to the gamepad. Well, probably never happen in USB connections but in theory BT connections may have some "radio wave" related issues.

Is the issue the same both over USB and BT?

I tested only through USB

Settings

rumbl.bug.mp4

Lunahria · 2021-01-05T17:25:10Z

The rumble persistence kept happening to a close friend of mine while he was playing Moonlighter. DualSense, DS4Windows 2.2.1 but ViGEm 1.16.112.0.

mika-n · 2021-01-05T22:51:27Z

Do you have 0,0,0 RBG color in the lightbar profile setting? If it is then try using something like 0,0,1 (ie. not all-zero) color. Any difference?

w1lddog2 · 2021-01-06T01:48:06Z

So far these i was able to gather from my own use:

-The issue started after updating to ViGEmBus 1.17.333.0

-Playing MK11 with native DS4 supports, the joystick works as intended and vibrates just fine.

-Steam Input work fines

I did change vibration to 1 seconds but the vibration is persistent.

mika-n · 2021-01-06T12:33:31Z

What about if you go back one by one previous releases to see if the issue (while using the same game) is "fixed" in some specific release? It would help to pin point the potential code change if this is a bug and not a game specific thing.

You can have several versions of DS4Windows installed at the same time in a separate folder. All those share the same config and profile files.
https://github.com/Ryochan7/DS4Windows/releases

w1lddog2 · 2021-01-06T13:40:57Z

I went back to 2.1.23 which was the version i had before the issue with the rumble and with that version same game, same profile the rumble works as intended.

RageSoul · 2021-01-06T14:33:49Z

Yep 2.1.23 rumble works perfectly

mika-n · 2021-01-07T07:37:21Z

Strange. I really cannot duplicate this "persistent rumble" bug with the latest version.

Some time ago when there was a bug in ViGem client driver, Dolphin gameCube/WII emulator was one app where this bug was easily seen even via the Dolphin . Nowadays and with the latest Vigem 1.17.333 and DS4Windows 2.2.1 I cannot duplicate this bug. However, I don't have any game ROMs for Dolphin but in the old days the rumble bug popped up even via controller configuration screen when testing rumble. Therefore it is still potentially possible that the bug occurs only via a specific game in Dolphin, but I cannot test those games you listed.

Have you found any freeware games/apps/gamepad tester apps where you can duplicate this bug?

So, is this gamepad or game specific issue or a profile setting? Please attach a zipped DS4Windows profile here.

And make sure you all have the latest ViGem 1.17.333 vigem driver installed and if you have ever installed the ancient ScpToolkit tool then all traces of ScpToolkit is removed. The DS4Windows logfile should show the version stamp of DS4Windows app itself AND ViGem driver.
https://github.com/ViGEm/ViGEmBus/releases

w1lddog2 · 2021-01-07T13:11:33Z

Here is the profile.

MK11.zip

"So, is this gamepad or game specific issue or a profile setting?"
To be honest till you asked i didn't tried any other game. Because lately i been playing only MK11.
So I just tried a few others games, like RE2 remake, RE3 remake, bayonetta and they work fine but they are xinput only, while MK11 has native support for DS4 joystick and the profile i use with that game is set to DS4 emulated controller.

mika-n · 2021-01-07T13:23:33Z

And exclusive mode or HidGuardian works for sure (ie. the game is not accidentally picking up the physical original ds4 gamepad)? What do you see in JOY.CPL controlPanel applet when DS4Windows is running and the gamepad is connected and using the MK11 profile?
https://github.com/Ryochan7/DS4Windows/wiki/Exclusive-Mode-(Hide-DS4-Controller-config-option)-tips-and-issues

@w1lddog2 Seems like there are posts from many people. You haven't post the latest DS4Windows logfile and how it looks like when you launch DS4Windows app, connect the gamepad and try to run the game until the bug is experienced and then close DS4Windows app and take a backup copy of the latest logfile (%APPDATA%\DS4Windows\Logs folder). You can then rename the logfile as .TXT file and drag-n-drop it here.

Ryusennin · 2021-01-07T14:20:38Z

I have to get back on my statement. I've just tested version 2.2.1 with Horizon Zero Dawn, and I can almost systematically reproduce the persistent vibration by rolling/dodging around. It can usually happen in a couple of tries -- although sometimes it won't lock until the 30th attempt!

I "platinumed" the game about 3 months ago with DS4W 2.1.x and never experienced persistent rumble in almost 200 hours of gameplay. I'm not sure wether the current behaviour is linked to version 2.2 or the new ViGEm, I'll have to make further tests with previous builds. Right now I'm unable to revert to 2.1 because of multiple "index was outside the bounds of the array" errors and crashes. Maybe due to incompatible profile formats?

Pylon69 · 2021-01-07T14:25:21Z

I'm not sure wether the current behaviour is linked to version 2.2 or the new ViGEm, I'll have to make further tests with previous builds.

I'm pretty sure it's not the ViGEm as I hadn't updated that ever since I installed DS4 tool 2 or so years ago. I only updated it to the latest after I was asked to try updating it. I'm pretty certain(and this is corroborated by others in this thread) it's the latest update that has brought this about since a rollback removes the issue

mika-n · 2021-01-07T14:34:39Z

And to make sure I understood correctly if using the same ViGem client version 1.17.333 things are working fine in DS4Windows 2.1.23, but when using DS4Windows 2.2.0 version in the same PC with the same game then rumble goes woooow
https://github.com/Ryochan7/DS4Windows/releases

And all you having this problem are using a profile with dualshock4 output controller type or does it make a difference if profile is in xbox360 output mode?

Too bad I don't have any game or test app or Dolphin rom where this bug is experienced. Hopefully @Ryochan7 has some games listed above because it is very difficult to fix without first being able to duplicate the bug. There are few changes between 2.2.0 and 2.1.23 which might cause some issues even when "should not cause any issues" (yeah, we all have heard that numerous times in this business).

Reboot70 · 2021-01-07T14:55:41Z

I'm only experiencing this issue on version 2.2.1 onward, as well as with whichever vigem driver. Please refer to the comment I posted earlier on this thread.
This issue is easy to reproduce in the Xinput rumble test from within Dolphin. If you bind both motors to rumble then hit "test", after the test period the rumble retains.
I've confirmed this issue also persists on Cemu, Redout Enhanced Edition, Borderlands 2, Duck Game. I've tried with DSU client as well on Dolphin and Cemu, which yields the same problems. Log files still indicate nothing, sadly.
Please let me know if you need more information or other ways to try and debug.

Pylon69 · 2021-01-07T15:18:35Z

And all you having this problem are using a profile with dualshock4 output controller type or does it make a difference if profile is in xbox360 output mode?

Sorry for the lazy phone pic.
But if xbox360 for input DS4 is what you mean then yes.

Ryusennin · 2021-01-07T15:45:42Z

For added info, my test with Horizon was with emulated X360 controller, not emulated DS4.

mika-n · 2021-01-07T16:03:17Z

Finally good news! Sort of. I was able to re-procedure the bug with Dolphin gamepad configuration screen. Indeed things work just fine when only one motor is rumbling at the time, but if both motors are included as "OR" operator in Dolphin then sometimes the rumble gets stuck (or only one of the motors is stopped and the other one remains rumbling).

At least there is now something to debug in details. I did this test using xbox profile.

Pylon69 · 2021-01-07T16:06:20Z

Sweet.

mika-n · 2021-01-07T16:55:42Z

@Ryochan7 Any ideas about the following debug log dump?
I debugged the "stuck rumble motor" issue using the latest 2.2.1 (actually the latest devel code, not yet published) version and interesting findings. Looks like sometimes the ViGemFeedbackEventHandler in DS4Windows app code never receive the Large=0 Small=0 event and that's why the other rumble motor gets stuck.

The bad news is that don't know yet if this is a bug in DS4Windows code, in ViGem .NET client interface or in the ViGem 1.17.333 C/C++ native client DLL library or in the worst case in the ViGem 1.17.333 kernel device driver level.

The bug seems to happen only when there are many rumble events within very short period of time (ie. I keep pressing the Test rumble button in Dolphin controller configuration screen few times rapidly to make it send startRumble-stopRumble-startRumble-stopRumble commands right after each other.

At this point I don't understand why this would work any better in 2.1.23 version using 1.17.333 ViGem driver because the feedback handler is pretty much the same code. Except that V2.1.23 comes with older version of .Net ViGem interface and ViGem native C/C++ client DLL library. Hmmm........

//ControlService.cs.EstablishOutFeedback.
Nefarius.ViGEm.Client.Targets.Xbox360FeedbackReceivedEventHandler p = (sender, args) =>
{
   AppLogger.LogToGui($"Large={args.LargeMotor} Small={args.SmallMotor}", false);
   SetDevRumble(device, args.LargeMotor, args.SmallMotor, devIndex);
};

01/07/2021 18:31:15: Large=0 Small=255           
01/07/2021 18:31:15: Large=255 Small=255         
01/07/2021 18:31:16: Large=255 Small=0
01/07/2021 18:31:16: Large=0 Small=0

01/07/2021 18:31:18: Large=0 Small=255
01/07/2021 18:31:18: Large=255 Small=255
01/07/2021 18:31:19: Large=255 Small=0
01/07/2021 18:31:19: Large=0 Small=0

01/07/2021 18:31:25: Large=0 Small=255
01/07/2021 18:31:25: Large=255 Small=255
01/07/2021 18:31:26: Large=255 Small=0

At this point the large rumble motor was stuck at rumbling state.
Notice how Large=0 Small=0 message is never shown and received in feedback eventHandler method.

I waited about 4-5 mins until I pressed the "Test" button again in Dolphin Controller configuration screen.
To my surprise "the lost" Large=0 Small=0 message was received at this point.
Almost like the message was waiting in some queue and when the new event came in then the feedback event queue was flushed and the "the lost" Large=0 Small=0 message was sent just before the new Small=255 message.

01/07/2021 18:35:05: Large=0 Small=0           ! This and the event in the next line came in almost at the same time !
01/07/2021 18:35:05: Large=0 Small=255       !  Beginning of the "next" rumble test event !  
01/07/2021 18:35:05: Large=255 Small=255
01/07/2021 18:35:06: Large=255 Small=0
01/07/2021 18:35:06: Large=0 Small=0           ! At this point the stuck rumbling was successfully stopped !

Ryusennin · 2021-02-11T16:45:33Z

I spent 10 minutes rolling around and using the weapon wheel in Horizon Zero Dawn (my test case for persistent vibration) and I didn't experience a single occurrence of locked rumble, which previously happened very quickly. I didn't notice any regression either in other games so far. Thank you for the fix!

Link to the test binary:
https://github.com/Ryochan7/DS4Windows/blob/919a05303be78c3f4dcb8083e2fbebac859ab83e/DS4Windows/libs/x64/Nefarius.ViGEm.Client/Nefarius.ViGEm.Client.dll

Ryochan7 · 2021-02-11T18:07:54Z

I didn't mention it in the previous post but it is apparent in the diff file. The force feedback changes only impact Xbox 360 controller emulation. I have not included a similar change for DS4 controller feedback yet. Upon further testing, it seems like force feedback is more on point with what I would expect in Streets of Rage 4. There had been some odd times using the stable library when it seemed rumble did not activate when it should in that game previously.

I might have to look into the more thorough queue system that mika-n had in place beforehand rather than using my older simple version. It seems like some type of change should be implemented in the next version of DS4Windows.

mika-n · 2021-02-11T19:38:14Z

I might have to look into the more thorough queue system that mika-n had in place beforehand rather than using my older simple version. It seems like some type of change should be implemented in the next version of DS4Windows.

The old ring-queue of IO overlap handlers uses (or used when it was still part of the ViGem client code) the exact same logic as your diff patch. Except that it is easier to maintain and change the size of the ring-queue using the code I submitted about year ago into ViGem code base.

Limyx826 · 2021-02-12T18:22:10Z

Just throwing in a report from somewhere by me.

I was trying to play Kingdom Hearts Re:Chain of Memories on PCSX2. When I hit a wall or get hit by enemy, vibration occurs as usual but doesn't stop. I'm using Dualshock 4 to x360 with DS4Windows. Even when I stop PCSX2 the vibration continues until either I unplug my controller or close DS4Windows.

This doesn't happen on others PS2 games like Kingdom Hearts 2 and others. Even when I used DS4Windows with other PC games, the vibration is just normal. It only happen with Kingdom Hearts Re:Chain of Memories.

After update the ViGem driver to 1.17.333.0, the problem fixed then again certainly curious it only happen with specific games.

Pylon69 · 2021-02-12T19:03:24Z

Just throwing in a report from somewhere by me.

I was trying to play Kingdom Hearts Re:Chain of Memories on PCSX2. When I hit a wall or get hit by enemy, vibration occurs as usual but doesn't stop. I'm using Dualshock 4 to x360 with DS4Windows. Even when I stop PCSX2 the vibration continues until either I unplug my controller or close DS4Windows.

This doesn't happen on others PS2 games like Kingdom Hearts 2 and others. Even when I used DS4Windows with other PC games, the vibration is just normal. It only happen with Kingdom Hearts Re:Chain of Memories.

After update the ViGem driver to 1.17.333.0, the problem fixed then again certainly curious it only happen with specific games.

Just don't update your ds4 till the bosses fix it and you'll be fine. Looks like the vibration issue is particularly, particular. Read through the whole thread and don't worry. I doesn't look like its DS4's fault entirely but I'm sure they can fix it.

Ryochan7 · 2021-02-12T19:56:56Z

I feel like a Boomer when it comes to C++. I have not used some of the newer tech included in the C++11 standard. Been using Qt abstractions for too long.

Got an adapted version of the notification queue set up and it works. I have not updated the diff yet. Not sure what use case caused the queue to use 6 entries and it is not specified. My old version used 4 mainly due to the Retroarch test. I have not tried to see if a lower number of entries would work with the current driver. Although, I guess some considerations need to be made for people still using the older ViGEmBus driver.

Updated: Diff has been updated

mika-n · 2021-02-12T21:05:14Z

I think the ring-queue size of 6 was just a scientific random number being "big enough, but not too big queue".

Limyx826 · 2021-02-13T08:18:09Z

Just throwing in a report from somewhere by me.

I was trying to play Kingdom Hearts Re:Chain of Memories on PCSX2. When I hit a wall or get hit by enemy, vibration occurs as usual but doesn't stop. I'm using Dualshock 4 to x360 with DS4Windows. Even when I stop PCSX2 the vibration continues until either I unplug my controller or close DS4Windows.

This doesn't happen on others PS2 games like Kingdom Hearts 2 and others. Even when I used DS4Windows with other PC games, the vibration is just normal. It only happen with Kingdom Hearts Re:Chain of Memories.

After update the ViGem driver to 1.17.333.0, the problem fixed then again certainly curious it only happen with specific games.

Oh yeah, forgot to mention. I test the vibration issue with the steam x360 emulation and they don't have the problem.

valentyn-l · 2021-02-13T13:23:59Z

So from the feedback I've gathered and my own experience, this issue is most commonly experienced in emulators such as PCSX2, CEMU, and Dolphin.

Ryochan7 · 2021-02-14T03:42:38Z

Implemented the notification queue for DS4 feedback support. The vigem_rumble_testing branch has been updated with the newer library.

Ryusennin · 2021-02-14T20:04:32Z

It works nice on both Win10 and Win7 (tested with RDR2 by walking through brambles for 10 minutes).

Test library:
https://github.com/Ryochan7/DS4Windows/blob/268bb654953189c993bbe0b81d0153e9e15820e4/DS4Windows/libs/x64/Nefarius.ViGEm.Client/Nefarius.ViGEm.Client.dll

Ryochan7 · 2021-02-17T19:03:54Z

Changed the library to use smart pointers again. I would like to compile the x86 version of the updated library and prepare to merge the vigem_rumble_testing branch to jay by the end of the day. Hopefully a new release will be able to come out soon.

…ET bug Related to issue #1730

Ryochan7 · 2021-02-18T02:30:28Z

That was a PITA. The library would just not work when compiled for x86. Spent a lot of time thinking the problem was due to the new code. The relevant problem was with differing function arguments for the notification callback created in the ViGEm.NET library. I am betting the problem affected the x64 side as well but it wasn't critical there. Error caught in Debug mode

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

The error stems from a change in the C++ ViGEmClient library dating back to 2020/04/01.

nefarius/ViGEmClient@f09f487#diff-6df313892aa43132e69781ab52bc6eb927f8483fb0fe3d02c4dfee70bcf8c3fd

Going to have to submit a fix upstream as this problem desperately needs to be fixed.

Ryochan7 · 2021-02-18T19:33:19Z

Submitted a pull request upstream and Nefarius has merged it. After this task, I feel like skipping other possible tasks and just pushing out a new DS4Windows release.

Ryochan7 · 2021-02-18T23:04:12Z

Version 2.2.7 is now out. Hopefully this issue is resolved for good

derrickb · 2021-02-18T23:20:11Z

Thank you for all your work on fixing this! Will do thorough testing in Cemu tomorrow.

Also, perhaps it would be helpful to provide more consumer-friendly changelogs? I wouldn't know the rumble issue was fixed from reading the latest one for 2.2.7

Ryochan7 · 2021-02-18T23:31:49Z

I didn't want to pollute the Changelog with ViGEm library changes. Luckily the Changelog is not bundled in the app so it can be updated at any time. The changed file will be loaded in the app when the update window is opened. I can add a line regarding the infinite rumble issue in a bit.

Pylon69 · 2021-02-19T08:44:28Z

Thanks a bunch ryochan. I can finally update now.

w1lddog2 · 2021-02-22T16:16:38Z

I tested 2.2.7 with few games that had the issue and now they are working like they should.

dante3732 · 2021-03-03T13:20:43Z

I have infinite vibration in "A way out" on last version ds4windows.

dante3732 · 2021-03-05T21:31:53Z

Why closed? I have same problem...

Ryusennin · 2021-03-05T22:12:24Z

The problem is solved since version 2.2.7.

You say "same problem" but you didn't give any details. Which game? What symptoms?

Ryochan7 · 2021-03-05T23:02:41Z

I can only assume you are likely not using the latest DS4Windows with the updated Nefarius.ViGEm.Client.dll file. Other than that, if DualShock 4 output is being used then you are encountering a completely different issue; looks like that game might have DS4 button prompt support. Unfortunately for that one, that issue is not fixable right now as documented in #1389. I might just end up disabling DS4 feedback support again just to avoid posts like this.

#1389 (comment)

Related to issue #1730

dante3732 · 2021-03-06T08:06:21Z

I use last version ds4windows and nefarius. It fix PCSX2 and CEMU infinite vibration. But i play in "A way out" and in place whenneed to shoot from the back of a pickup with a shotgun, i have infinite vibration.
The game, by the way, natively supports dualshock 4, but I'm playing through ds4windows with an xbox profile.

mika-n · 2021-03-06T11:43:36Z

@Ryochan7 are you sure it is a good idea to disable feedback events in DS4 output mode? Now people keep bombing with questions why rumble doesn't work in DS4 output mode. I haven't experienced the issue since the latest version and those "overlapped IO controller call" tweaks in the vigem client DLL library.

If some people are having issues with rumble then they can disable the rumble per game profile by setting the rumble-% value to zero. Therefore I think it may not be good idea to completely comment out the code from the code, instead people complaining about this issue should upgrade to the latest version of DS4Windows+ViGem client and if nothing else helps then set the rumble-% value to zero to to set the rumble watchDog timer to X seconds.

mika-n mentioned this issue Jan 7, 2021

Vibration persists after being set to 0 nefarius/ViGEmBus#68

Closed

mika-n mentioned this issue Feb 15, 2021

Infinite vibration glitch #1873

Closed

Ryochan7 added a commit that referenced this issue Feb 18, 2021

Updated ViGEmClient libraries for both arch. Found a critical ViGEm.N…

cd89963

…ET bug Related to issue #1730

Ryochan7 closed this as completed Mar 5, 2021

Ryochan7 added a commit that referenced this issue Mar 5, 2021

Have to disable virtual DS4 feedback routine again

d01a9db

Related to issue #1730

CasualX mentioned this issue Jun 6, 2022

Notification API issues CasualX/vigem-client#4

Open

Persistent Vibrate/rumble #1730

Persistent Vibrate/rumble #1730

Comments

Pylon69 commented Jan 4, 2021

Lunahria commented Jan 4, 2021

mika-n commented Jan 4, 2021

Reboot70 commented Jan 4, 2021 • edited Loading

Pylon69 commented Jan 4, 2021 via email

w1lddog2 commented Jan 4, 2021

Pylon69 commented Jan 4, 2021

Ryusennin commented Jan 4, 2021

Pylon69 commented Jan 4, 2021

RageSoul commented Jan 5, 2021

mika-n commented Jan 5, 2021 • edited Loading

RageSoul commented Jan 5, 2021 • edited Loading

Lunahria commented Jan 5, 2021

mika-n commented Jan 5, 2021

w1lddog2 commented Jan 6, 2021

mika-n commented Jan 6, 2021

w1lddog2 commented Jan 6, 2021

RageSoul commented Jan 6, 2021

mika-n commented Jan 7, 2021 • edited Loading

w1lddog2 commented Jan 7, 2021

mika-n commented Jan 7, 2021

Ryusennin commented Jan 7, 2021

Pylon69 commented Jan 7, 2021

mika-n commented Jan 7, 2021 • edited Loading

Reboot70 commented Jan 7, 2021

Pylon69 commented Jan 7, 2021

Ryusennin commented Jan 7, 2021

mika-n commented Jan 7, 2021 • edited Loading

Pylon69 commented Jan 7, 2021

mika-n commented Jan 7, 2021 • edited Loading

Ryusennin commented Feb 11, 2021

Ryochan7 commented Feb 11, 2021

mika-n commented Feb 11, 2021

Limyx826 commented Feb 12, 2021

Pylon69 commented Feb 12, 2021

Ryochan7 commented Feb 12, 2021 • edited Loading

mika-n commented Feb 12, 2021

Limyx826 commented Feb 13, 2021

valentyn-l commented Feb 13, 2021

Ryochan7 commented Feb 14, 2021

Ryusennin commented Feb 14, 2021 • edited Loading

Ryochan7 commented Feb 17, 2021

Ryochan7 commented Feb 18, 2021

Ryochan7 commented Feb 18, 2021

Ryochan7 commented Feb 18, 2021

derrickb commented Feb 18, 2021

Ryochan7 commented Feb 18, 2021

Pylon69 commented Feb 19, 2021

w1lddog2 commented Feb 22, 2021

dante3732 commented Mar 3, 2021 • edited Loading

dante3732 commented Mar 5, 2021

Ryusennin commented Mar 5, 2021

Ryochan7 commented Mar 5, 2021 • edited Loading

dante3732 commented Mar 6, 2021

mika-n commented Mar 6, 2021 • edited Loading

Reboot70 commented Jan 4, 2021 •

edited

Loading

mika-n commented Jan 5, 2021 •

edited

Loading

RageSoul commented Jan 5, 2021 •

edited

Loading

mika-n commented Jan 7, 2021 •

edited

Loading

mika-n commented Jan 7, 2021 •

edited

Loading

mika-n commented Jan 7, 2021 •

edited

Loading

mika-n commented Jan 7, 2021 •

edited

Loading

Ryochan7 commented Feb 12, 2021 •

edited

Loading

Ryusennin commented Feb 14, 2021 •

edited

Loading

dante3732 commented Mar 3, 2021 •

edited

Loading

Ryochan7 commented Mar 5, 2021 •

edited

Loading

mika-n commented Mar 6, 2021 •

edited

Loading