== DETAILS
When I first implemented the Wii U HID architecture, I ended up
having to design my own implementation because, at the time, I did
not have a way to read the HID device string to allow the existing
code to successfully detect the gamepad.
After spending some time experimenting, I've figured out how to
do this. And that means I can better align the HID driver with other
platforms.
change summary:
- create a single state structure for all three sub-types of wiiu pads
(kpad, wpad, and hid)
- eliminate confusing duplicate pad lists
- eliminate confusing duplicate HID pad drivers (ds3, gamecube
adapter, etc)
- ensure the ds3 driver still works
== DETAILS
File this one under "I'm not sure how this ever worked."
I mean, it did (in 1.8.8). I'm not sure what changed, but ultimately what I did was
a bunch of comparative testing against 1.8.8:
- I confirmed the packet data was still being read successfully
- I confirmed that the axis value being passed into pad->get_axis() had
not changed
- I confirmed the work done in `gamepad_read_axis_data()` was working the same
between 1.8.8 and master
With the only difference between 1.8.8 and current being the return value from
`gamepad_read_axis_data()`, I just rewrote the method to work properly, and
also fixed up the default axis mapping.
I tested this with a sixaxis controller and GCA, configuring the analog-to-digital
control override to use the right stick.
== DETAILS
After a bisect, the culprit was changing the gamepad interface from
returing a single button (bool) to multiple (int16).
The issue is that the Wii U gamepad (and presumably the Pro controller too)
have more than 16 buttons, which means some buttons get lost. Notably, L3 (18)
and R3 (17).
The solution: use int32 instead of int16.
I did a test build and confirmed that this change restores L3/R3 functionality
with the gamepad. Don't have a pro controller to test, but it should work too.
== DETAILS
The way the mouse emulation worked was to simply return a 3rd axis from the
gamepad, which the polling code updates with the touch state in real time.
Well, the code that figures out if it's a positive or negative axis was
failing because it didn't see that 3rd axis as valid. So, I added values
which allow it to be seen as valid, and voila! the touch screen input
works again.
== TESTING
Tested locally using "Beneath a Steel Sky" in ScummVM.
== 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
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.
