== DETAILS
Thanks to JacobM at GBAtemp for helping me test this.
The WaveBird wasn't being properly picked up due to the port status byte
being different from normal GC controllers. (Why? who knows. Probably
so games could detect the WB and show WB-specific OSDs).
This implementation should be more future-proof, to handle any other
unexpected status bytes.
== DETAILS
So, the KPadRead function will sometimes return 0, but this doesn't mean
the wiimote is actually disconnected. It's usually something transient, like
the BT chip has nothing to send or whatever. I don't know.
So, I added a buffer so that it won't disconnect the pad without 5
consecutive 0-reads.
This is a temporary hack; a proper solution will use the Wii U's callback
mechanisms to do wiimote detection. But that's a separate project. This at
least prevents OSD spam.
== TESTING
Tested locally. Verified that connecting/disconnecting nunchuk during play
still works properly.
== DETAILS
This is the wiimote version of the same bug I previously fixed in the HID
driver, where disconnected pads didn't actually invoke the unregister task.
This has an extra wrinkle, in that we *also* need to invoke the unregister
task when the wiimote device changes (e.g. user plugs in a nunchuk or
classic controller).
Now, there's still the problem of the "disconnect" detection being broken; so
a consequence of this commit is OSD spam. However, the actual wiimote input
is processed successfully and there's no noticeable issues in the pad
handling.
== TESTING
Using Mario 3, I played a level in which I started as bare wiimote, then
hot-plugged the nunchuk, and the input switched automatically. At the
end of the level, I hot-unplugged the nunchuk and it automatically reverted
to horizontal layout; and the pad remained 100% responsive the entire time.
