Possible solution for 3rd party Wiimote disconnections?

[DaveyJC]

Hello all,

I'm new here though i've been using Dolphin for a long time.

I have a 3rd party Wiimote I bought from DX for my sister last year that wasn't
working, so I've downloaded Dolphin code and made some little
modification.

I would like anyone whose Wiimote is not working/disconnecting to try this build of mine of 3.5-108 x64 (just the .exe) --> http://depositfiles.com/files/bsacfjsbv

Tell me if it works for your previously disconnecting wiimotes! My lil sis' wiimote now works!

Thank you!

[pauldacheez]

Put up a .patch or .diff so we can look at what exactly you did to try to fix it, would you? (Distributing a modified binary without providing source violates the GPL anyway, if you needed more incentive.)

[DaveyJC]

I simply lowered the time the real Wiimote thread sleeps from 2ms to 1ms when m_audio_reports FifoQueue is empty, which seems to be most of the time.
This change is done in WiimoteReal.cpp, function Wiimote::ThreadFunc().

This fixes a no-brand-Wiimote bough in Dealextreme last year that was working correctly with GlovePie but not with Dolphin (vibrated but disconnected right away 99% of the times), so I thought it should be related to Dolphin's code. Another wiimote I have, also bought in DX but branded "Nintendo", worked perfectly with Dolphin.

I infer by this chage in code that this 3rd party Wiimote has to be read/written at least once each millisecond not to get disconnected. I've tried this change with Win7 MS stack & Toshiba 8 bluetooth stack.
As performance impact seems to be minimal (same FPS or maybe 1fps lower) on my machine, I think this change should be pushed to master, cause it probably will help with many 3rd party Wiimote connections/disconnections.

Should I do a push? Never did one :-)

diff --git a/Source/Core/Core/Src/HW/WiimoteReal/WiimoteReal.cpp b/Source/Core/Core/Src/HW/WiimoteReal/WiimoteReal.cpp
index 204a1fc..3c1d0f8 100644
--- a/Source/Core/Core/Src/HW/WiimoteReal/WiimoteReal.cpp
+++ b/Source/Core/Core/Src/HW/WiimoteReal/WiimoteReal.cpp
@@ -323,7 +323,8 @@ void Wiimote::ThreadFunc()
{
if (m_audio_reports.Size() && !read)
Read();
- Common::SleepCurrentThread(m_audio_reports.Size() ? 5 : 2);
+ //Common::SleepCurrentThread(m_audio_reports.Size() ? 5 : 2);
+ Common::SleepCurrentThread(m_audio_reports.Size() ? 5 : 1);
read = false;
}
#endif

[pauldacheez]

You can't push this into master yourself if you don't have commit access, of course. But a dev who knows somethin' about Wii Remotes might come by, look at the change and consider merging it in (crediting you, of course).

The change certainly looks like it'll help, but it may not be that 2 ms was too long an interval - my crackpot theory is that misbehaving remotes expect audio data every 5 ms (since that's the interval at which the DSP receives audio data from the CPU), and if the thread only wakes up every 2 ms, it was waking up at 4 and 6 ms but not at 5 ms, which third-party remotes don't enjoy. Feel free to test this out, of course, since I'm likely incorrect.

[DaveyJC]

My tests with this 3rd party wiimote of mine (fps on NSMBW intro with all 4 characters running, on a Phenom II@3.8/4G/5770/DX11):

Common::SleepCurrentThread(m_audio_reports.Size() ? 5 : 0); -> works (138 fps)
Common::SleepCurrentThread(m_audio_reports.Size() ? 5 : 1); -> works (144-145 fps)
Common::SleepCurrentThread(m_audio_reports.Size() ? 5 : 2); -> x (146-147 fps)
Common::SleepCurrentThread(m_audio_reports.Size() ? 5 : 3); -> x
Common::SleepCurrentThread(m_audio_reports.Size() ? 5 : 4); -> x
Common::SleepCurrentThread(m_audio_reports.Size() ? 5 : 5); -> x
Common::SleepCurrentThread(m_audio_reports.Size() ? 5 : 6); -> x
Common::SleepCurrentThread(m_audio_reports.Size() ? 5 : 10); -> x

I would be glad to see this change included in Dolphin code.

[pauldacheez]

Aww, my crackpot theory was wrong...

Oh, well. I'll ask the devs in the IRC to put this fix in.

[frainsa]

thank working with 3 wimote unoficial excellent.

[DaveyJC]

(01-02-2013, 03:32 PM)frainsa Wrote: thank working with 3 wimote unoficial excellent.

3 wiimotes that weren't previously working, right?

[frainsa]

yes they have´t trouble before, now working fine. only thing is don´t work game metroid prime other m after screem game pad. turn black. another think wirk fine LLE and speaker wimote sound great.
I think good option take this for newers revisions. sorry my english

[DaveyJC]

I need to say this 3rd party wiimote wasn't previously working on 2 different pc's with 2 different bluetooth chips. Now this wiimote is working on both.