== 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
- DS3 analog wasn't working mainly because I forgot to actually declare the
axes in input/input_autoconfig.c when declaring the pad. Whoops.
- I also moved the axis decoding logic to a more central place, because it
clearly is not Wii U specific.
- Removed some dead commented-out code
== TESTING
Can use analog inputs on both GCA and DS3. Tested in Mario 3 on Nestopia core.
Haven't tested with any actual analog games, but I did confirm via logging
that the correct ranges are produced.
== DETAILS
So, it turns out that there *is* a autoconfig disconnect handler. Took digging
through tasks/task_autodetect.c to find it!
So, I added a call to the handler when the pad gets disconnected.
This seems to solve the problem of the pad not disappearing from the menu.
(At the very least, the user's pad index reverts to "none" which is still
an improvement)
== TESTING
Tested manually, made sure it didn't crash or leak slots.
This should fix the issue where R/L buttons didn't register when doing
input detection.
This also brings the GC pad in line with the rest of the gamepads in
input_autodetect_builtin.c.
Also fixed a really stupid bug that was part of why analog inputs aren't
being read. Analog still isn't working, mind, but it's a lot closer to
working now that it's actually getting down into the pad driver level!
=== DETAILS
So, the GCA has 2 USB connections; one is the data connection, and the
second is used to drive rumble.
Due to a driver bug, if the second cable wasn't attached, the pads wouldn't
get detected.
I fixed that bug.
== DETAILS
Hooray for conditional compile directives.
Moving things around broke things in unexpected ways on non-WiiU builds.
Well, not *completely* unexpected. But still.
Changes:
- Move some typedefs around to avoid circular include dependencies
- Include the file where the HID driver definition got moved to
== TESTING
- verified build for Wii U still runs successfully
- did a local build without any errors (some weird warnings, but since they
happen in code I didn't change, I'm assuming they're pre-existing?)
== DETAILS
I think this will fix the problem with duplicate pads--pads weren't properly
de-initializing and registering as disconnected. When a pad is disconnected,
the slot should properly release now.
retro_bits_t turned into input_bits_t and there were parts of my
code that needed to update.
== TESTING
No idea if upstream changes broke anything, but it compiles cleanly
now.
== DETAILS
TIL that it's bad to call synchronization code from callbacks.
To avoid that, I made the following changes:
- Implemented an atomic swap (see previous commit) to avoid explicit
locking when working with the event list
- ensure locks are only acquired in either the main thread or the
I/O polling thread
- use an explicit polling loop; we still use async reads, but the
read doesn't immediately re-invoke itself.
- remove the sleep in the polling thread.
- remove unnecessary locking in the thread cleanup call--verified that
the list can't be modified while it is being executed.
== TESTING
I tested locally, and was able to disconnect/reconnect USB devices several times without the worker thread getting deadlocked.
Fortunately, the gcc port implements the builtins and, from basic
testing, they seem to work.
This is only really useful on Wii U--other platforms have more
robust atomic operations, or aren't using gcc to build.
- remapping analogs to buttons works 100%
- remapping analogs to other analogs still messed up for some reason
- need to reset input of the original axis in input_driver.c still
radius