mirror of
https://github.com/dolphin-emu/dolphin.git
synced 2024-11-15 13:57:57 -07:00
012939d127
the occasional HLE wiimote disconnection, although nowhere it was at near the level before both the recent wiiuse integration and adding the queue in the first place. The callback-based bluetooth input method on OS X really requires that packets be accepted immediately and the 1ms polling done by the wiimote worker threads isn't quite good enough. So just play along with the native OS X model and send the packet up our stack directly from the callback. With our current API, this is kind of a layering violation, but it seems less messy than either putting back internal queueing in IOdarwin.mm or adding the platform support for higher-frequency polling than what usleep(3) offers. Perhaps we should just change our own API to a callback model. While this makes no real difference right now, it would make it a fair bit cleaner to accept new wiimotes at any time instead of having to click Refresh, although with the recent realmote changes, that feature can probably just be hacked in by looping around FindWiimotes(). For other platforms having problems with HLE disconnections caused by dropped bluetooth packets, as a first stop I would suggest trying to do more than just one wiimote->Read() per iteration in the thread. This change also conveniently sidesteps another new IOdarwin.mm bug where the discovery and I/O code would clash during a refresh because they use the same default CFRunLoop, so if we switch back to using a run loop for I/O, must remember to create a separate one. git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6743 8ced0084-cf51-0410-be5f-012b33b47a6e |
||
|---|---|---|
| .. | ||
| Core | ||
| DSPSpy | ||
| DSPTool | ||
| Plugins | ||
| PluginSpecs | ||
| TestSuite | ||
| UnitTests | ||
| CMakeLists.txt | ||
| Dolphin.sln | ||