WiimoteReal: Windows improvements.

[jordan-woyak]

Majorly overhauled the Windows Wii remote code.

Statically link with "Bthprops.lib"
Dynamic linking was introduced in 3acf0eb to make Dolphin run under Wine.
My search results imply that Wine has long since added stubs for these functions so I'm hoping it works fine now?
I'll change it back if not.
edit: Wine seems to work fine.

A 10 year old comment describes a workaround needed for the Toshiba Bluetooth stack.
I've removed the workaround.

Removed HidP_SetOutputReport fallback (Windows 7 workaround).

Fixed buggy overlapped Read/Write event usage (probably my fault from long ago).

Added checks for a Wii remote device name on the HID interface to only attempt connecting to actual Wii remotes devices.
The existing code just throws Wii remote data at every interface and checks for sane replies.

Added a periodic write to test for disconnected remotes in a timely manner.

Changed the Refresh button to not remove authenticated remotes.
Some users found it annoying.
It now only removes unauthenticated disconnected remotes.

Added Sync and Reset actions to establish and remove pairings.
The Refresh button is now a QToolButton with additional actions (only on Windows).

Pairing a remote with the Sync button will enable it to reestablish a connection on any button press.
The UX still needs improvements.
The buttons block the UI and It's really not clear what's going on behind the scenes unless you watch the logs.
I plan to rectify this.

Refresh or Continuous Scanning are no longer required to connect paired remotes.
Pairing with Windows or the DolphinBar "just works" by assigning a slot to Real Wii Remote.

Additionally, I am constantly bombarded with ControllerInterface / WiimotePool related deadlocks.
This seems like an existing issue that fixing properly is probably going to take another PR.
It seems like it's SDL?
I've disabled SDL's DirectInput handling for now.

This PR still needs some work but maybe some people would like to do some testing. :)

TODO for this PR:

• Make the Sync / Reset buttons display some kind kind of feedback and also not block the UI.
• Make the Sync button also open the HID interface.
• Test Dolphin with Wine
• Figure out why SDL is blocking on a DirectInput call or just leave it disabled?
• Clean up log spam from continuous opening of HID interfaces.

[mbc07]

The last version of the Toshiba Bluetooth stack was released in 2011, it's not available from Toshiba anymore and I highly doubt it works on Windows 10+, which is the minimum we require for Dolphin nowadays. With that said, I think it's safe to drop workarounds for it...

[Trihy]

Will test later and report back.

About this

// When pressing the sync button, the remote expects the host's mac as the pass key.
// When pressing 1+2 it expects its own mac.
// I'm not sure if there is a convenient way to determine which to use?
// And using the wrong method makes Windows disconnect the remote..

I think in both cases the mac (Wiimote or host) needs to be in backward order. Just for keeping the code nicely explained.

[Trihy]

Some things I noticed. Only tested with nsmb. Still takes some time to dolphin realize a wiimote was turned off. Seems unpredictable the time. But kind of works. Until you get the wiimote disconnected message, obviously wont reconnect. After the message will reconnect fine.

When using just 1 player on nsmb, wiimote 2 will be disconnected by emulated software (4 leds will stay on) which is correct, but when going back to dolphin UI will still show 4 leds on and wont get player led until launching a game, we can improve this.

Reconnecting them on dolphin UI without launching games at all was partially possible, they reconnect, but no player led is assigned until a game is launched (they keep blinking until a game is launched)

All those test were made with continuous scan enabled.

Will share more discoveries, but it`s looking good.

[MayImilae]

A 10 year old comment describes a workaround needed for the Toshiba Bluetooth stack.
I have left the workaround in place for now.
I have not tested the Toshiba Bluetooth stack, it seems like it's super not relevant anymore?
Does anyone still use it? Should I just remove the workaround?

I am someone who used (and technically still uses) a bluetooth dongle compatible with the Toshiba Stack. I hunted down an Azio BTD-V201 specifically for the better bluetooth connectivity and support for -TR Wii Remotes back in the Windows 7 days. But I no longer use the Toshiba Stack, since it was a nightmare to use and Windows 8 made the windows bluetooth stack less terrible, enough that the now minor benefit of the Toshiba Stack wasn't worth it. Fortunately my Azio BTD-V201 supported bluetooth passthrough so I'm still using it to this day as a bluetooth passthrough adapter.

I imagine most people who used to use the Toshiba Stack are in a similar position to me. The Toshiba Stack hadn't been updated for years when I purchased mine in 2013 and I highly doubt you can find a device that shipped with it in the past decade, so, I extremely doubt anyone is using it still. Even if they are, they should have moved on to something else by this point.

I am totally ok with you removing a workaround for it, especially when many easier and better options exist.

[jordan-woyak]

Some things I noticed. Only tested with nsmb. Still takes some time to dolphin realize a wiimote was turned off. Seems unpredictable the time. But kind of works. Until you get the wiimote disconnected message, obviously wont reconnect. After the message will reconnect fine.

Yeah, for whatever reason, it seems like detecting a disconnect is not possible until performing a write, which we currently wait for the game to do. The situation could definitely still be improved.
Sending a no-op rumble report every second if nothing has been written by the game would probably work.

I think in both cases the mac (Wiimote or host) needs to be in backward order. Just for keeping the code nicely explained.

Bluetooth MACs are usually stored in an order reverse from display order, so it's "normal" order, but I'll make that clear in the comment.

Reconnecting them on dolphin UI without launching games at all was partially possible, they reconnect, but no player led is assigned until a game is launched (they keep blinking until a game is launched)

When I experience this sort of situation, I find it's usually from one of the various Wii remote threads deadlocking with another. I don't think it's strictly related to the Wii remote communication. It seems this is an existing issue.

[Trihy]

Continuous scan is similar to Windows BT searching for devices mode?

I noticed some BT dongles while are searching for devices, they take a good hit in performance (ie. headset could skip audio while on this mode). If continuous scan do the same, could be a performance improvement if we could get rid of this for reconnecting purposes.

I tested both nonTR and TR and they work pretty good. All functions are ok. Dolphin no more deleting them from system. Although didnt test sync capabilities.

[jordan-woyak]

Continuous scan is similar to Windows BT searching for devices mode?

I noticed some BT dongles while are searching for devices, they take a good hit in performance. If continuous scan do the same, could be a performance improvement if we could get rid of this for reconnecting purposes.

Continuous Scanning is currently the same as repeatedly pressing the Refresh button.
It does a Bluetooth inquiry, tells windows to enable the HID service on discovered devices, then separately enumerates installed devices to open any Wii remote HID interfaces.

Ideally just the final step would happen repeatedly, then we could detect re-connections without Bluetooth inquiries.
I have these functions separated in the Windows-specific IOWin code now, but the WiimoteScanner interface probably needs a redesign to accommodate the separate functionality.

[jordan-woyak]

Update:
WiimoteScanner now continuously checks for new HID interfaces without needing to press Refresh or use the slow and problematic Continuous Scanning.

Disconnects are now detected in about one second.
After using the Pair button, pressing any button on the remote will reconnect it to Windows and Dolphin will automatically find it.
It also works with the DolphinBar.
The Wii remote experience is no longer bad.

I've disabled SDL's DirectInput handling for now to work around deadlocks.

[Trihy]

Lot of improvements. Will report back later.

BTW anyone has a tplink ub500? Im almost sure wiimotes wont reconnect with that dongle. Dont know what realtek messed there, since it's 8761B based. Wonder if the problem affects other 8761B based like the asus one among others.

I had a talk with them and after many debug info they sent me a working driver. But never make it to public release. In case you find some weird troubles with that one, just let me know. I dont know where I left the ub500 to test it again.