== DETAILS
(I think)
- Uncomment the call in the read loop to start feeding packets to the
driver
- implement the GCA packet driver
- implement the pad interface
- fix indentations in GCA driver
== TESTING
Compiles. Haven't tested yet.
== DETAILS
Turns out the cause of the crash was a bad cast, resulting in a
function call to nowhere.
Also, I think the DSI exception handler only works on the primary core;
when this was happening in the background thread, I got a black
screen error instead.
Next up: finishing up the GCA driver.
== DETAILS
We're at a point where we need to do more than just
clean up a local data structure, so I've started
implementing the "detach" part of the code so that
everything gets cleaned up properly.
Also, added error handling inside the polling
thread.
== TESTING
Have not tested yet.
== DETAILS
I've created the concept of a hid_driver_instance_t which is basically
a central place to store the hid pad driver, hid subsystem driver,
the pad list, and the instance data for the above in a central location.
The HID pad device drivers can use it to perform HID operations in a
generic manner.
This is more-or-less a pause point so I can catch up with upstream.
== TESTING
Haven't tested this yet. Compiles without warnings though!
== DETAILS
- detect() methods in device_* files now check for VID/PID
instead of just returning false
- add "name" field on hid device, mainly for logging purposes
== TESTING
Verified my WiiU GC adapter detected properly
Add some timing functions so that we can know the time (woo-hoo?)
I use errno here, which worries me a bit. I wouldn't put it past
devkitPPC to have it as a null pointer or something.
Can confirm this makes XMB's clock work, much to @cucholix's delight;
I'm sure ;D
== DETAILS
When I split out wiiu_gamepad into multiple sub-drivers, I missed a spot.
The code expects the device type to be initialized to a magic number
(0xfd), and instead it was getting initalized to zero, which meant it
never triggered the detection process.
I re-added the initialization, and now it works.
== TESTING
Tested with nestopia core to confirm autodetect and game response works.
== 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.
