Closed nefarius closed 5 years ago
I've already butchered in a pool of threads which queues more requests pending in the driver and thus - not entirely fix - drastically reduces the chances of the queue running dry. So now I'm not losing packets anymore but now of course concurrency issues arise.
Invoking the notification function pointer/delegate within the same thread should be moved to a different worker thread and received packets shall be handed over via linear synchronized queue.
I've butchered the master branch quite a bit, my apologies, but I now found a way to deal with it properly via WinAPI, stay tuned.
It's Easter "holidays" here but I am still sober enough to get back to this, you shall be fixed if it's the last thing I'll do 😱
There we go https://youtu.be/uzNcQfxaMF0
Next some clean-up, more tests and applying the same to the DS4-code and we're ready to ship 😅
Thx for the fix. Rumble feedback seems to work now and no more lost events (at least when tested as part of DS4Windows app).
Based on this branch? Or on a workaround by DS4Windows?
Based on the fix in ViGemClient client library (as used via C# .NET library in DS4Windows). Well, not sure which branch Ryochan7 used but I guess it is the fix in this branch.
DS4Windows app does have a fallback "max rumble timeout" to stop the rumble if it seems to be running exceptionally long time without any feedback updates from ViGemBus/Client. But I have tested the new ViGemClient without this fallback timeout also to test whether the client side fix really does the trick. The good news is that I haven't seen any stuck rumble motors in those scenarios where it used to get stuck before this VigemClient fix (or fallback timeout workaround).
Great, thanks for the feedback. Next is to polish my horrible C++ shenanigans, implement proper clean-up and do the same for the DS4 route and we shall be on our route to victory 😎
You know what they say: "If it works, don't fix it". But being a software developer I know that "cleaning up a code" is not the same as "fixing something which isn't broke" :-)
Nah by cleaning up I mean properly address all of the legacy code fragments and possibly leaking memory because I wanted to get a working prototype fast and "make it right" later 😉
Finally done 🎉
Describe the bug Rumble feedback inconsistent. Request packets may get lost or come in out of order.
To Reproduce Write a Feeder using the feedback callback/event and produce rumble requests with e.g. Dolphin Emulator (like so)
Expected behavior Rumble packets should arrive in the syme order as submitted to the driver via XInput API.
Screenshots![image](https://user-images.githubusercontent.com/286631/56028784-30743b00-5d19-11e9-8f00-e766feff69c8.png)
System details (please complete the following information):
Additional context Original report