== DETAILS
We're trying to track down the source of crashes when switching cores.
To rule out the HID code, this commit does the following:
- Wraps the library imports in an ifdef
- Wraps the object files in conditionals in Makefile.wiiu
- In wiiu_joypad, calls into the hidpad driver are wrapped in ifdef
== TESTING
This didn't solve the "System memory error" crash I've been experiencing.
But, maybe it will impact the other flavors of crashes others are seeing.
== DETAILS
Well, after a lot of code analysis, this seems like the
best way to handle things on the Wii U without also completely
re-architecting the I/O handling in RetroArch.
How it works:
- the top-level wiiu_joypad driver is now nothing more than a
delegator.
- the wiiu-specific drivers live in `wiiu/input/`
- wpad_driver.c handles the WiiU gamepad
- kpad_driver.c handles the wiimotes
- hidpad_driver.c will handle HID devices like the GC adapter, DS3/DS4, etc.
(I say "will" because this isn't implemented yet)
== TESTING
Haven't actually tried the build to see if it works, but it does
compile.
== DETAILS
Looking at the apple input driver gave me an idea--moving the
HID driver into the wiiu_input_t data instead of piggy-backing
it off the wiiu_joypad driver.
- Remove changes to wiiu_joypad
- Add equivalent to wiiu_input
This is probably broke as hell. Haven't tried to compile.
== DETAILS
I did a minimalist edit of the HID thread that stripped out all
HID* syscalls, and this stopped the crashing. I then re-added just
the HIDSetup() and HIDTeardown() calls, and the crash came back.
This smells like an OS bug. To work around it, I've put the
HIDSetup() and HIDTeardown() calls into the app init/shutdown
section, so they only get called once in the application lifetime
and not each time the input driver is initialized.
== DETAILS
We discovered that the controller_patcher code was causing
the WiiU to intermittently crash when switching ROMs.
Changes:
- Completely extricates the controller_patcher code
- Create a skeleton wiiu_hid driver
- Wire up the build system to build/link it successfully
== TESTING
Has not been tested. Probably doesn't crash, since the
skeleton driver is just a copy of the null driver.
As discussed in libretro#5357; controller_patcher is now optional. It's
off by default; though this could be changed with a simple makefile
tweak (ENABLE_CONTROLLER_PATCHER ?= 1, perhaps?)
To re-enable controller_patcher; append ENABLE_CONTROLLER_PATCHER=1 to
your usual make command.
controller_patcher was the only user of c++ constructors in the Wii U
port, so you'll need 26a006c in your tree otherwise you will have a
blackscreen on startup.
Oops! Didn't do this quite right the first time round.
This commit fixes RETRO_DEVICE_ID_POINTER_PRESSED, which would always
return 0 due to to an implicit case to int16_t. Basically, we'd do
(val & 0x00080000) & 0xFFFF; which would return 0 every time. Fixed that
by wrapping it in a ternary. Yes, I know we could use a rotation, but
for a boolean value it really doesn't matter.
I also rewrote scaleTP to deal entirely in integers. While the
floating-point math was theoretically faster on PowerPC; it gets awkward
to cast -0x7FFF to a float.
Speaking of, the driver now actually conforms to the libretro API. Not
sure how I managed to not see the spec; but hey, now its fixed.
RETRO_DEVICE_POINTER_ID_X/Y will now return values between -0x7FFF and
0x7FFF like they're supposed to.
Big thanks to @r-type for hounding me to fix this.
Partially addresses #5294; we still need mouse emulation.
This hopefully fixes the issues when you try to use 2 Controllers with
the same vid/pid at the same time.
Tested with 2 DS4 controller via the Hid to VPAD Network Client.
Adapters with multiple ports (like the official GC-Adapter) are still
working
