== DETAILS
- fix the bitshift math
- read the right bytes out of the ds3 data packet
- remove verbose logging in critical path
- stop caring about errors in the hid read loop -- seems to just
be benign "device not ready" -- or at least, that's what I'm assuming
given that the read eventually succeeds.
== TESTING
Played Mario 3 with the DS3 with no issues.
== DETAILS
- update to not try starting the read loop until after the device
is successfully initialized
- add new HID wrapper macros needed by ds3 driver
- add some debug logging to help with troubleshooting
- add button map for DS3
== TESTING
Tested with local build. DS3 init is not working.
== DETAILS
Whereas the last commit had a hack (that disabled the wiimote
driver in the process), this has.. well, a *different* hack that
allows pads to register in any order.
Note that due to the initialization routines, the gamepad will still
likely always get slot 0. Not sure if this can be overridden via config
or not.
== TESTING
Tested locally with GC adapter
== DETAILS
Now that I have a working implementation, it's time to tidy up a bit:
- there was no need for the HID subsystem's object data to have a reference
to the global hid state (since it's global), so removed it.
- refactored the users of that member to use the global state, defining
reusable macros.
- reorganized the information in *.h files
- removing the hid state also made the constructor changes to the hid driver
unneeded, so I reverted those changes.
== TESTING
Confirmed clean build. Haven't tested the build yet to make sure everything
still works, though.
== DETAILS
- Added a new method to the joypad_connection_t interface for
getting a single button
- wired everything into the hidpad driver
- for testing purposes, hacking the top-level joypad driver
so that kpad isn't used
- add a new RARCH_LOG_BUFFER method to verbosity for logging the
contents of a binary buffer (useful for writing/debugging pad drivers)
- fix a few bugs in the wiiu GC pad driver
The button mapping isn't quite right, and I'm not sure what's
going wrong.
== DETAILS
Trying to do weird pad math just wasn't working so I bit the bullet and just
let it allocate all 16 pads in the slot list, then just mark 0-4 as
connected so that the slot allocator would start at 5.
I can see it detect the pad, but no idea if it works. Out of time for
today.
== DETAILS
Turns out freeing memory that's already been freed is.. bad.
Fix two double-free instances; one due to over-freeing and the other
due to wrong order-of-operations causing a double free.
Also updated logging a little.
== TESTING
The GC adapter still clobbers slot 0, but the "emergency exit" sequence
works to quit RA cleanly.
== 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.
