Skip to content
This repository has been archived by the owner on Jan 1, 2024. It is now read-only.

Won't re-connect when computer wakes from sleep #3023

Closed
Kazserah opened this issue Jul 22, 2023 · 13 comments
Closed

Won't re-connect when computer wakes from sleep #3023

Kazserah opened this issue Jul 22, 2023 · 13 comments

Comments

@Kazserah
Copy link

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
Screenshot_1

@Ryochan7
Copy link
Owner

Ryochan7 commented Jul 23, 2023

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
Copy link
Author

I downgraded to the previous version and now everything is fine

@Kazserah
Copy link
Author

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

@Ryochan7
Copy link
Owner

Ryochan7 commented Nov 26, 2023

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 Ryochan7 reopened this Nov 26, 2023
@Ryochan7
Copy link
Owner

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
Copy link
Owner

Ryochan7 commented Nov 27, 2023

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Owner

Ryochan7 commented Nov 29, 2023

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

49e889f

@Ryochan7
Copy link
Owner

Updated ViGEmClient change

Ryochan7/ViGEmClient@f6747cf

@Ryochan7
Copy link
Owner

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
Copy link
Owner

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants