Rumble state is not always sent to client code

nefarius / ViGEmClient

ViGEm Client SDK for feeder development.

https://docs.nefarius.at/projects/ViGEm/

MIT License

134 stars 65 forks source link

Rumble state is not always sent to client code #3

Closed nefarius closed 5 years ago

nefarius commented 5 years ago

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

System details (please complete the following information):

OS: all
Feeder software: all using the feedback events, either native or managed
Driver Version: all up to this point

Additional context Original report

nefarius commented 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.

nefarius commented 5 years ago

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.

nefarius commented 5 years ago

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 😱

nefarius commented 5 years ago

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 😅

mika-n commented 5 years ago

Thx for the fix. Rumble feedback seems to work now and no more lost events (at least when tested as part of DS4Windows app).

nefarius commented 5 years ago

Based on this branch? Or on a workaround by DS4Windows?

mika-n commented 5 years ago

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).

nefarius commented 5 years ago

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 😎

mika-n commented 5 years ago

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" :-)

nefarius commented 5 years ago

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 😉

nefarius commented 5 years ago

Finally done 🎉