== DETAILS
1. Noticed that the HID driver wasn't loading after setting WIIU_HID=1. Found
that the HID driver init was ifdef'd out. Removed that.
2. Current theory around "System Memory Error 160-2203" is in-memory
corruption. So, to try to identify it:
- Created a routine that does a hex dump of the RPX over the logger. (I
have a python3 script that can extract the hex dump back into a binary
file). If a SME occurs with this routine enabled, we can see if the
corruption is happening at read-time, or somewhere between when we send
the RPX to the loader and try to execute it.
- I noticed that we allocate slightly more memory than the RPX actually
needs, and we don't zero the memory, which means there's a handful of
bytes at the end that could be anything. I added a call to memset() to
zero out the memory prior to loading the RPX off the SD card.
And, of course, after adding those, I haven't been able to reproduce the
System Memory Error, so maybe the uninitialized memory was the problem?
Here's hoping.
== DETAILS
- Add *.swp to gitignore so editor swap files don't get committed
- Remove unneeded commented-out defines from WiiU build
- Start on fix for DSI when switching cores on WiiU
== TESTING
Sigh. I'm back at "System Memory error", which makes me think the problem
might be the SD card. (On the plus side, I manually verified the hash so
at least the copy process is working).
So, that's to say that I can't actually test to see if the DSI error is
fixed.
== 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
TIL that the "max_packet_size_*" fields in the HIDDevice struct
are actually requirements, not maximums.
The reason HIDRead() was blocking was because the HIDWrite() that
sent the activation command was silently failing.
The reason HIDWrite() was silently failing was because I was using too
small of a buffer for the device.
In this case: the Wii U GC adapter, which has a "max" tx packet size of 5.
"max" is misleading. You actually have to write all 5 bytes.
Which means: copying the 1-byte buffer to the 5-byte buffer, and writing
the 5-byte buffer via HIDWrite().
So, in summary:
- Use correct semantics for HIDWrite() so that HIDRead() can work.
- Update the OSThread struct to reflect the current knowledge over at
WUT. It's unlikely this was actually causing a problem, but never
hurts to be more correct.
== TESTING
I temporarily enabled the call to log_buffer() and confirmed that the
GC adapter's state is successfully being read.
== 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
can load *.slangp and *.slang files. since there is no runtime compiler,
precompiled shaders (*.gsh) need to be present next to each *.slang
source file.
== 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
- 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
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.
== 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
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.
Thanks for @gblues for finding the strcmp bug.
I've removed the opcode display since it's a bit unsafe - if the
exception handler causes a DSI; Cafe OS will take over and freeze up the
console. This is obviously not a good thing. There are possible
situations where memory is executable and not readable; so this is just
about covering all bases until a better solution can be implemented.
Maybe we can experiment a bit more once this handler isn't being used so
often ;)
