Dolphin, the GameCube and Wii emulator - Forums

Hey all

Forgive me - this is a long post, but I wanted to be thorough in reporting what I think is a bug!  For this post, I'm only really concerned with Wii emulation, not GC.

I've been running build 5.0-6152 on my main gaming machine with real (genuine Nintendo) WiiMotes+WiiMotionPlus addon using pass-through for ages and it's been great.  However, I wanted to get in on the Ubershader action so I decided to download the latest build (5.0-8751 at time of writing).

Some notes:  I'm using Zadig 2.4 version with Libusbk drivers on a Sena UD100 Bluetooth Adapter.

When launching a any Wii game with 8751, I now get a black screen, then the windows driver "bingly-bong" noise as the bluetooth connection is attempted.  However WiiMotes won't pair and the game just hangs on the black screen.  All I can do is press escape to kill the game, which then gets stuck in the "Shutting down..." stage for over a minute before finally quitting out, getting the "bingly-bong" windows driver sound again and returning to the UI.

My ini looks like this:  (extract):
[BluetoothPassthrough]
Enabled = True
VID = -1
PID = -1
LinkKeys = e0:e7:51:fe:ae:1e=a0d364e4c95acb7a818a160d0487f149,00:19:1d:a8:cc:8f=e1a120217201101c2096823300f971ff

...but I've also tried blanking LinkKeys.

I can see with logs enabled that the correct Bluetooth adapter device is detected.  I've also tried a clean/vanilla copy of this build with no luck.

The Dolphin log looks normal until the following line:

25:30:363 core\ios\usb\bluetooth\btreal.cpp:126 N[IOS_WIIMOTE]: Using device 0a12:0001 (rev 8241) for Bluetooth:

...where it hangs for 10 seconds - just less ;-) - and then I see the following:

25:39:843 core\ios\ios.cpp:565 W[IOS]: Previous request to device /dev/usb/oh1/57e/305 blocked emulation for 9443323 microseconds.
25:51:848 core\hw\exi\exi_deviceipl.cpp:357 N[OSREPORT]: BTU HCI command timeout - cmd opcode = 0xc24
25:59:864 core\hw\exi\exi_deviceipl.cpp:357 N[OSREPORT]: BTU HCI command timeout - cmd opcode = 0xc13
26:07:879 core\hw\exi\exi_deviceipl.cpp:357 N[OSREPORT]: BTU HCI command timeout - cmd opcode = 0xc0a
26:15:896 core\hw\exi\exi_deviceipl.cpp:357 N[OSREPORT]: BTU HCI command timeout - cmd opcode = 0xc33
26:23:912 core\hw\exi\exi_deviceipl.cpp:357 N[OSREPORT]: BTU HCI command timeout - cmd opcode = 0x1001
26:31:927 core\hw\exi\exi_deviceipl.cpp:357 N[OSREPORT]: BTU HCI command timeout - cmd opcode = 0x1009
26:39:944 core\hw\exi\exi_deviceipl.cpp:357 N[OSREPORT]: BTU HCI command timeout - cmd opcode = 0x1001
26:41:487 core\ios\usb\bluetooth\btreal.cpp:660 E[IOS_WIIMOTE]: libusb transfer failed, status: 0x03
26:41:516 core\ios\usb\bluetooth\btreal.cpp:660 E[IOS_WIIMOTE]: libusb transfer failed, status: 0x03

For comparison, the log from 5.0-6152 look like this:

29:29:224 IOS\USB\Bluetooth\BTReal.cpp:126 N[IOS_WIIMOTE]: Using device 0a12:0001 (rev 8241) for Bluetooth:
29:29:380 IOS\IOS.cpp:565 W[IOS]: Previous request to device /dev/usb/oh1/57e/305 blocked emulation for 134274 microseconds.
29:29:619 IOS\IOS.cpp:565 W[IOS]: Previous request to device /dev/usb/oh1/57e/305 blocked emulation for 109200 microseconds.
[.... normal log continues and game starts.  WiiMote connects when I turn it on etc....]

SO!! I played detective and wondered if I could find a build in between 6512 and 8751 that would work.  I looked through the build list and changelog and tested every version in between that had changes relating to Wiimote code.  

Long story short...  
5.0-8093 worked fine (change was WiimoteDevice: Remove unnecessary cast (PR #7105 from lioncash)
5.0-8098 did NOT work and had the exact same behaviour I'd seen in the latest build!  The changelog says that the following change was made in 8098:

BTReal: Fix unsafe reinterpret_casts (PR #7103 from leoetlino)  -----  IS THIS THE OFFENDING CHANGE?

5.0-8096 (which had a JitBase change) also worked fine.

I also sometimes see the IPCEvent bug mentioned in the PR, but note every time: https://github.com/dolphin-emu/dolphin/pull/7103

Is it possible that this change (or in combination with other changes not listed?) has broken real Wiimotes?  I'm guessing there'd be a lot more posts if it had broken for everyone, but I guess it could just be for my adapter, or driver version (libusbK (v3.0.7.0))?

Given how stable (perfect I'd say) my adapter has been with the Wiimotes for the last year or so, I'd be disappointed if this combo no longer works.

I've tried all sorts of config changes to get this to work and I think I've exhausted all the options.

Can someone please help with this issue?

Many thanks.

Machine spec:  Lenovo e72 - i7-3770S - 16GB corsair RAM - Asus Nvidia 1050Ti (latest driver) - Windows 10 Pro (1709 Build 16299.309)

Hey

I've done a bit more reading. Looks like PR7216 from leoetlino resolves the regression, but it hasn't been accepted yet.

Any reason why this fix (which seems to have been confirmed in the forum) hasn't been accepted back into the codebase?

Thanks.

UPDATE: I've test PR#7216 against the latest master and it fixes the issue.

PR#7116 didn't fix it for me unfortunately :/

(10-02-2018, 02:47 AM)e2zippo Wrote: [ -> ]PR#7116 didn't fix it for me unfortunately :/

Well, it´s expected since you chose the wrong one (7216 is the one you´re looking for).

nah, they made a typo, they commented in the PR that it didn't fix it for them.

My bad, typo! PR#7216 didn't help me :/

(10-02-2018, 02:47 AM)e2zippo Wrote: [ -> ]PR#7116 didn't fix it for me unfortunately :/

Was passthrough working before (in builds earlier than 5.0-8098)?
Do your error messages look the same?

(10-04-2018, 12:42 AM)Craftyawesome Wrote: [ -> ]Was passthrough working before (in builds earlier than 5.0-8098)?
Do your error messages look the same?

It's been a bit dodgy for some time, but I don't think I've seen the IPC error message before, I can try with a build before 5.0-8098.

(10-07-2018, 05:49 AM)e2zippo Wrote: [ -> ]It's been a bit dodgy for some time, but I don't think I've seen the IPC error message before, I can try with a build before 5.0-8098.

The IPC error seems persistent.  However, if you turn of Panic Handlers then it won't bother you and everything is peachy.  PR-7216 has now been merged with the master so all updates contain the fix now.