== 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
The BIT256_GET() macro expects a bit number (from 0-255), and we're giving it
a 32-bit mask (0x000080000).
Solution:
- Define VPAD_BUTTON_xxx_BIT macros using the bit number
- Use said macro in wiiu_input.c
- organizational cleanup:
* put VPAD_BUTTON_TOUCH into the enum in stead of as a hokey define
* put the touch bits in the right order
* put in placeholder enums for (currently) unused bits
== DETAILS
I fixed a similar bug in a past commit, with the same root cause: making
assumptions about the length of the array.
- Add validation to joypad_connection_init() so that if >MAX_USERS is
requested, a warning is logged and only MAX_USERS is allocated.
- Rewrote the iteration routines so they strictly use the
joypad_is_end_of_list() method to detect the end.
== 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
- the free() method of the hid_driver_t interface needs its
parameter defined as const in order for the compiler to stop
complaining about losing const-ness.
- if a joypad list is created with <MAX_USERS slots in it, the
destroy() function will crash because it assumes there are MAX_USERS
entries.
To do this, the allocate function creates n+1 slots, and gives the
last slot a canary value that the destroy() method can then watch for
when iterating through the list.
== 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
USB Vendor and Product IDs are in little-endian byte order, and they
need to be byteswapped on big-endian systems.
This approach allows us to use the standard hex notation for the VID/HID
values, and give them meaningful names, and only swap on the platforms
that need it. Also prevents having to abuse SWAP16() in the platform-
specific code.
== DETAILS
I haven't figured out how I'm going to get the data read via HIDRead()
funneled back to the adapter--the handle_packet() method doesn't actually
get called anywhere.
I'm probably going to need to do more tweaking to the function pointer
list.
This commit also adds logging for the data read via HIDRead.
== TESTING
I used my "stress test" (which I used to reproduce the crash caused
by the old HID implementation), and it did not crash.
== DETAILS
Starting to implement the I/O handling on the HID driver.
The old implementation basically had a never-ending HIDRead() callback
set up, so that callback N would start the read process for invocation
N+1.
We will take the same approach here; but now that the I/O thread is
happenning on its own core, we should be able to let it run full-
throttle without impacting emulator performance.
Of course, this hinges on the callback actually running on the same
core as the syscall was initiated on.
== TESTING
Can confirm that the read_loop_callback gets invoked on the same core
that the HIDRead() was invoked on.
== DETAILS
This implements the WiiU-specific functions.
Since the wiiu_hid_t data structure contains the handle and interface
index, the method signatures can be simplified quite a bit. And since
(at least for now) we want these to be synchronous, we don't need to
expose the callback parameters.
== DETAILS
The handshake stuff is derived from the old HID2VPAD, just in knowing
what data goes in what report.
- Added the HID_REPORT_ flags to syshid.h
- Renamed the generic "REPORT_TYPE" flags to be meaningful
- also fixed incorrect parameter list for set_protocol
== TESTING
The functions aren't implemented in wiiu_hid.c just yet,
so this is gonna crash if you try to run it.
== DETAIL
One minor detail missed in the last commit: actually putting the
send_control function into the driver declaration. Woops.
Not doing the Wii U because it will be using the other methods.
== DETAILS
The current HID implementation assumes a very low-level USB library
is being used. This causes a problem on Wii U, because the Cafe OS
only exposes a high-level interface.
To get these functions exposed to the HID pad drivers, I had to make
three changes:
1. I added the legacy "send_control" function to the HID driver
interface
2. I modified the signature of pad_connection_pad_init() to send the
driver pointer instead of the function pointer
3. I updated the HID pad drivers to keep the pointer to the driver
instead of the function pointer, and updated the calls into the
send_control function as appropriate
4. I updated the HID drivers to use the new pad init signature
== TESTING
Untested, in theory it should work without a hitch because at this
point all I've done is abstract things a little. I still need to
update the HID pad drivers to use the Wii U-specific calls as
appropriate.
== 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
- Added entrypoints into `input/connect/joypad_connection.c` to allow
a max value to be passed in, instead of using single macro value
- Created a hand-off between the HID attach handler and the worker thread
- Created a pad initializer in `wiiu_hid.c` leveraging the new functionality
added to `joypad_connection.c`
== TESTING
Compiles cleanly. At best, doesn't do anything. Might crash--not ready
to test quite yet.
== DETAILS
After wasting some cycles trying to isolate a crash, I went back to
basics.
I enabled the network logging, and put in a bunch of logging lines,
and noticed that the HID thread wasn't actually starting.
I did quite a bit of experimenting, working with different
memory alignments, and finally got it working.
== TESTING
As you can see, I put a log output inside the worker thread. When
I run the build, I can see the TICK messages. I can also see that
the thread shuts down as expected.
Also! The HID callback works as expected too! I have the GC
adapter, and when I register the HID callback it fires and I get the
following data:
[INFO] USB device attach event
[INFO] handle: 2058729
[INFO] physical_device_inst: 0
[INFO] vid: 0x7e05
[INFO] pid: 0x3703
[INFO] interface_index: 0
[INFO] sub_class: 0
[INFO] protocol: 0
[INFO] max_packet_size_rx: 37
[INFO] max_packet_size_tx: 5
Note that these are raw dumps of the data passed to the method,
so e.g. the VID/PID might be byte-swapped from how they're usually
represented.
Have not done the stress test to try to reproduce the crash.
== DETAILS
The old code was crashing; I did a minimalized branch and the crash
went away, so I'm bringing that over here. Meaning I'll have to
redo some of the other work I'd put in, but oh well.
(now watch it start crashing again)
== TESTING
Can confirm it builds. Wii U is busy ATM so I can't test.
== 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
I think I've about got the thread startup/teardown code worked
out. Logically, anyway, if not accurately.
The challenge has been figuring out how best to integrate the
features of HID2VPAD.
I found `input/connect/joypad_connection.c` and this seems like
the logical place for:
- Special-case driver for the Switch Pro controller
- Any other special cases HIDTOVPAD supports that core RetroArch
doesn't
- Parsing of HIDTOVPAD config file to add custom button mapping
== TESTING
Compiles. Haven't tested with a real Wii U. Probably doesn't work
though. I very likely have the threading bit wrong.
== DETAILS
Looking at the other HID USB drivers, it looks like the typical
implementation is to start up a background thread to do the
polling, rather than wait for RA to invoke the poll() method.
This commit sets up the skeleton of the background thread:
- The thread gets created in init()
- The thread gets stopped in free()
Right now the body of the thread is a 10ms sleep.
== TESTING
It compiles cleanly, and links. Don't know if it actually works.
== DETAILS
I think I've about got the thread startup/teardown code worked
out. Logically, anyway, if not accurately.
The challenge has been figuring out how best to integrate the
features of HID2VPAD.
I found `input/connect/joypad_connection.c` and this seems like
the logical place for:
- Special-case driver for the Switch Pro controller
- Any other special cases HIDTOVPAD supports that core RetroArch
doesn't
- Parsing of HIDTOVPAD config file to add custom button mapping
== TESTING
Compiles. Haven't tested with a real Wii U. Probably doesn't work
though. I very likely have the threading bit wrong.
== DETAILS
Looking at the other HID USB drivers, it looks like the typical
implementation is to start up a background thread to do the
polling, rather than wait for RA to invoke the poll() method.
This commit sets up the skeleton of the background thread:
- The thread gets created in init()
- The thread gets stopped in free()
Right now the body of the thread is a 10ms sleep.
== TESTING
It compiles cleanly, and links. Don't know if it actually works.
