Won't re-connect when computer wakes from sleep

[Kazserah]

When my computer wakes, I go back to ds4windows and it says no controllers connected, i hit start, nothing happens (it still says start), so I have to close and re-open the program.

This was never an issue since the last update.

According to the log it says "ViGEm Device Plugin Failed. Likely an internal ViGEmBus problem" etc

[Ryochan7]

I still have no idea is happening there. I do not use Sleep but this error has not occurred to me since finally getting it working on my PC.

On a side note, I see where that lock recursion is taking place. The lock is not released when ViGEmFailure is fired. I need to fix that.

[Kazserah]

I downgraded to the previous version and now everything is fine

[Kazserah]

This is happening again with the latest version. Nothing has changed on my end.

[Ryochan7]

Not much I can really do about it. Testing this scenario with ViGEmBus calls commented out always seemed to work IIRC. It was rare for me to be able to replicate the issue to start with. The only real way around the problem would be to have a very extended wait period on the Resume step (I think 3 minutes).

I will reopen this issue temporarily and see if I can run into the problem again. My ongoing hypothesis has been that the problem is something within ViGEmBus itself but there has been no way to verify it completely. I was gaslit for years about the infinite rumble problem in ViGEmBus and had to make workarounds in a custom ViGEmClient library. Only recently was I able to confirm and fix that problem on my end within the ViGEmBus driver code.

If something were found, it would not truly matter as I have no means to distribute a custom driver.

[Ryochan7]

So far, I only have a better idea about where the process is failing. A request made by ViGEmBus times out before an LED packet is sent from the XUSB driver which would cause ViGEmBus to fire an event. The real error code does not propagated back up to the client as a target removal is done when the routine fails with any status. The error code from vigem_target_remove is propagated back up.

https://github.com/nefarius/ViGEmBus/blob/master/sys/EmulationTargetPDO.cpp#L691

https://github.com/nefarius/ViGEmBus/blob/master/sys/XusbPdo.cpp#L843

[Ryochan7]

Only done a bit of playing around since the previous post. Interesting enough, changing the client code to just ignore the error results allows for XInput emulation to work. Not sure if imposing an additional wait period in the client code would be enough to work around the problem or maybe trying additional times. Trying again outside the client library is a problem due to the forced target removal step and the wrong error code being sent back.

There might be the case that the driver code that is supposed to signal the event is not executed. It would be much harder to try to diagnose that problem since WPP Tracing messages likely cannot be traced in a client that early.

One other thing to mention is that there are some odd times when this problem pops up outside of resuming from sleep.

[Kazserah]

Thanks for checking it out. For the moment, I'm using 3.2.12 with VigEmBus version 1.22 and it's working fine atm, so I'll wait and see what else you find

Do you think you'll implement that code change?

[Ryochan7]

Tested it multiple times and adding an extra wait period before the call (1 sec) is enough to make the process work every time on my PC. I do not want to add a wait period for every plugin event when not needed so I will have to test adding multiple attempts instead. At least this type of workaround would be doable in the client library although the problem does originate at the driver level. It would probably have be better if the entire process were written as a blocking call instead.

[Ryochan7]

This would go faster if my PC would cooperate. Tested the multiple attempts method and it is confirmed to work on my PC. The second attempt is able to grab the signaled status and the virtual XBox 360 controller works as expected. I currently have the loop set to attempt up to 3 times. Hopefully that will be enough attempts to work around this issue and still allow for more severe errors to cause DS4Windows to disconnect from ViGEmBus.

[Ryochan7]

Updated libraries. I'll get the updated code out there shortly.

49e889f

[Ryochan7]

Updated ViGEmClient change

Ryochan7/ViGEmClient@f6747cf

[Ryochan7]

Got the .NET 8 libraries updated with the changes included as well.

3389828

This is likely the best that can be done without having to change the ViGEmBus driver itself. It looks like there would still be the possibility for a rare race condition to occur regarding PdoBootNotificationEvent since the EmulationTargetPDO::WaitDeviceReadyCompletionWorkerRoutine clears the event even on a timeout. There might be a small chance the event is signaled after the timeout but before that method ends. In that case, it looks like a second XUSB_LED packet would have to be sent in time to not have the routine fail needlessly. It is too bad the timeout used in the method cannot be adjusted.

I will keep this issue open until the next DS4Windows release.

[Ryochan7]

Looks like this issue can be safely closed this time around. Not an ideal solution but at least the root problem is known and a workaround is in place.