== DETAILS
This should fix#6025.
After confirming that dummying out the init block of the HID subsystem
driver eliminated the crash, I narrowed it down to the event loop.
And that's when I noticed that, when the thread consumes the event,
it doesn't free it.
Oops.
Updated the event loop to free the event after it has been processed.
== TESTING
Local build, was able to load multiple ROMs in succession where prior
I was getting the system memory errors.
I've #if 0'd out a call to HIDRead that is still getting deadlocked,
because it slows down the startup/shutdown process.
== DETAILS
The joypad driver was only copying the first 16 bits when executing
get_buttons(). The touchpad button is bit 19, so as a result
RETRO_DEVICE_ID_POINTER_PRESSED would never fire.
We fix this for now by copying 32 bits.
== TESTING
Will need someone to verify. I don't have a core handy that leverages
the pointer device state functionality.
== DETAILS
@r-type got me the link to the fixed-fixed version.
Which was actually closer to where I was originally!
So:
- Revert the previous commit
- Apply the actual changes needed to fix the problem
- Bring in and fix the logging code from the previous implementation
== TESTING
- Verified that top-left is -0x7fff,-0x7fff and that bottom-right is
0x7fff, 0x7fff.
== REVIEW
@QuarkTheAwesome @r-type @twinaphex
== DETAILS
Apparently when I refactored this code, I missed out on the fix for
touchpad coordinates that @QuarkTheAwesome had committed.
Oops.
- Fix the touchpad coordinates
- Remove unneeded references to video driver in wpad_driver.c
- Remove unneeded video driver include in pad_driver.h
- Add logging in wpad_driver to verify the fix (#ifdef'd out by default)
== TESTING
Verified fix manually.
== DETAILS
If a call to HIDRead() ends up blocking indefinitely, it will
cause the shutdown process to wait forever.
To avoid a deadlock, I've put in a retry counter so that it will
give up after 5s and print a warning to the log.
== DETAILS
RetroArch's general HID drivers are intended as a full-on substitute for
other input drivers such as XInput, DInput, SDL, etc. The Wii U port is,
to my knowledge, the first case of heterogenous input drivers working
concurrently.
As such, I've moved things around:
- The HID driver source is moved into the wiiu/input/ directory alongside
the joypad subdrivers.
- We no longer use the input_hid_init_first() method to instantiate; instead
we just init the wiiu HID driver directly.
- The HID pad driver and HID subsystem driver enjoy a tighter coupling,
mainly having to do with the initialization of the joypad connections
list, because there's no way to inform the HID driver's init() method
how many slots to allocate.
== TESTING
Will test in a moment, but at least it compiles cleanly. ;)
== DETAILS
The gamepad didn't work because I had tried to rename the pad from
'WIIU Gamepad' to 'WiiU Gamepad'.
I added some debug logging and (to cut out a lot of trial-and-error)
discovered that the reason it didn't work was because a bug in a macro
was using the define literally instead of substituting it (so e.g.
the autodetect handler was trying to match 'WiiU Gamepad' against the
literal string 'PAD_NAME_WIIU_GAMEPAD').
- Fixed the macro bug
- Left a minimal amount of the debug logging in place; may come in
handy for someone else.
- Updated wpad/kpad/hidpad to use the define constants
== TESTING
Did a test build and confirmed the gamepad responded.
== 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.
